From teemu.savolainen@nokia.com Fri Jul 1 00:05:33 2011 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 B08BF21F8586 for ; Fri, 1 Jul 2011 00:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.923 X-Spam-Level: X-Spam-Status: No, score=-1.923 tagged_above=-999 required=5 tests=[AWL=-0.677, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, MIME_BASE64_TEXT=1.753, 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 wptq+MzDhkP9 for ; Fri, 1 Jul 2011 00:05:33 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 2898421F857C for ; Fri, 1 Jul 2011 00:05:32 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p6175R7h021828; Fri, 1 Jul 2011 10:05:27 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Jul 2011 10:05:26 +0300 Received: from 008-AM1MMR1-001.mgdnok.nokia.com (65.54.30.56) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 1 Jul 2011 09:05:26 +0200 Received: from 008-AM1MPN1-036.mgdnok.nokia.com ([169.254.6.18]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0289.008; Fri, 1 Jul 2011 09:05:26 +0200 From: To: , , Thread-Topic: [BEHAVE] What is the purpose to consider the non-standard IPv6address formats in NSP discovery using WKN? Thread-Index: AQHMN71AWImZj/fd3E61e6Em54OfNw== Date: Fri, 1 Jul 2011 07:05:25 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 01 Jul 2011 07:05:26.0924 (UTC) FILETIME=[4134FCC0:01CC37BD] X-Nokia-AV: Clean Subject: Re: [BEHAVE] What is the purpose to consider the non-standard IPv6address formats in NSP discovery using WKN? 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, 01 Jul 2011 07:05:33 -0000 SSB3YXMgbm90IHJlYWxseSBpbnZvbHZlZCB3aGVuIHRoZSBhZGRyZXNzIGZvcm1hdHMgd2VyZSBk ZWZpbmVkLCBhbmQgaGVuY2UgSSBkb24ndCBrbm93IHdoeSBzb21lb25lIGNvdWxkIG5vdCBjaG9v c2UgdG8gdXNlIGUuZy4gLzcwIHdpdGggc3VmZml4IGluaXRpYWxpemVkIHRvIHplcm8uIEknbSBh bHNvIHVuYXdhcmUgaWYgRE5TNjQgaW1wbGVtZW50YXRpb25zIHNwZW5kIGVmZm9ydCB0byBlbnN1 cmUgYWRtaW5pc3RyYXRvcnMgZm9sbG93IFJGQzYwNTIgZ3VpZGVsaW5lcyBvciBpcyBpdCB2ZXJ5 IGVhc3kgdG8gZGVmaW5lIHdoYXRldmVyIE5TUD8gKGkuZS4gV2hhdCB3aWxsIGJlIHRoZSBhY3R1 YWxseSBhZGRyZXNzIGZvcm1hdHMgdXNlZCBpbiBsaXZlIG5ldHdvcmtzKS4NCg0KQW55aG93LCBp ZiBubyBvdGhlciBjb21tZW50cyBJIHdpbGwgY2hhbmdlIHRoZSBkcmFmdCBhcyBDaHJpc3RpYW4g c3VnZ2VzdGVkIChyZW1vdmUgc2VjdGlvbiwgYWRkIGEgbm90ZSkuIEkgZG8gYWdyZWUgaXQgc2lt cGxpZmllcyBhbmQgY2xhcmlmaWVzIHRoZSBkb2N1bWVudC4NCg0KVGhhbmsgeW91IGZvciBjb250 cmlidXRpb25zLA0KDQpUZWVtdQ0KDQoNClRlZW11DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBleHQgbGl6aGVucWlhbmdAY2hpbmFtb2JpbGUuY29tDQpTZW50OiAgMDEvMDcv MjAxMSwgMDU6MzQNClRvOiBDaHJpc3RpYW4gSHVpdGVtYTsgU2F2b2xhaW5lbiBUZWVtdSAoTm9r aWEtQ1RPL1RhbXBlcmUpOyBiZWhhdmVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBSRTogW0JFSEFW RV0gV2hhdCBpcyB0aGUgcHVycG9zZSB0byBjb25zaWRlciB0aGUgbm9uLXN0YW5kYXJkIElQdjZh ZGRyZXNzIGZvcm1hdHMgaW4gTlNQIGRpc2NvdmVyeSB1c2luZyBXS04/DQoNCkkgYWdyZWUgd2l0 aCBDaHJpc3RpYW4gSHVpdGVtYS4gV2UgbmVlZCBub3QgdG8gc3RhbmRhcmRpemUgdGhlIG5vbi1z dGFuZGFyZCB0aGluZy4NCg0KWmhlbnFpYW5nIExpDQoyMDExLTA3LTAxDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBDaHJpc3RpYW4gSHVpdGVtYQ0KU2VudDogMjAxMS0wNy0w MSAgMDU6Mjc6MTkNClRvOiAgdGVlbXUuc2F2b2xhaW5lbkBub2tpYS5jb207IGJlaGF2ZUBpZXRm Lm9yZzsgbGl6aGVucWlhbmdAY2hpbmFtb2JpbGUuY29tDQpTdWJqZWN0OiBSRTogW0JFSEFWRV0g V2hhdCBpcyB0aGUgcHVycG9zZSB0byBjb25zaWRlciB0aGUgbm9uLXN0YW5kYXJkIElQdjZhZGRy ZXNzIGZvcm1hdHMgaW4gTlNQIGRpc2NvdmVyeSB1c2luZyBXS04/DQoNCj4gT24gdGhlIG90aGVy IGhhbmQsIEkgZG9uJ3Qgc2VlIHdoeSBhIG5vZGUgc2hvdWxkIG5vdCBhdHRlbXB0IHRvIGRldGVj dCBub24tc3RhbmRhcmQgTlNQLg0KDQpEZXRlY3RpbmcgYSBub24tc3RhbmRhcmQgTlNQIGlzIG9u bHkgdXNlZnVsIGlmIHRoZSBub2RlIHVuZGVyc3RhbmRzIGhvdyB0aGUgbm9uc3RhbmRhcmQgYWRk cmVzc2VzIGFyZSBidWlsdCwgd2hpY2ggcHJlc3VtYWJseSByZXF1aXJlcyBhIGJpdCBtb3JlIHRo YW4gc2ltcGxlIHBhdHRlcm4gbWF0Y2hpbmcuDQoNCkkgdGhpbmsgaXQgd291bGQgYmUgc2ltcGxl ciB0byBwbGFjZSB0aGUgbm9uLXN0YW5kYXJkIE5TUCBhcyBmaXJtbHkgb3V0IG9mIHNjb3BlIGZv ciB0aGUgInN0YW5kYXJkIiBkaXNjb3ZlcnkgZHJhZnQuIFlvdSBjYW4gYWx3YXlzIGFkZCBhIHNp bXBsZSBwYXJhZ3JhcGgsIHNvbWV0aGluZyBsaWtlDQoNCiJEZXZlbG9wZXJzIE1BWSBvdmVyIHRp bWUgbGVhcm4gb24gSVB2NiB0cmFuc2xhdGVkIGFkZHJlc3MgZm9ybWF0IHRoYXQgYXJlIGV4dGVu c2lvbnMgb3IgYWx0ZXJuYXRpdmVzIHRvIHRoZSBzdGFuZGFyZCBmb3JtYXRzLiBUaGV5IE1BWSBh dCB0aGF0IHBvaW50IGFkZCBhZGRpdGlvbmFsIHN0ZXBzIHRvIHRoZSBwcm9wb3NlZCBkaXNjb3Zl cnkgcHJvY2VkdXJlcy4gVGhlc2UgYWRkaXRpb25hbCBzdGVwcyBhcmUgb3V0c2lkZSB0aGUgc2Nv cGUgb2YgdGhlIHByZXNlbnQgZG9jdW1lbnQuIg0KDQotLSBDaHJpc3RpYW4gSHVpdGVtYQ0K From zhengyli@cisco.com Sun Jul 3 21:35:55 2011 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 D43EB1F0C78 for ; Sun, 3 Jul 2011 21:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.684 X-Spam-Level: X-Spam-Status: No, score=-9.684 tagged_above=-999 required=5 tests=[AWL=0.915, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 Ub2brjncnHf2 for ; Sun, 3 Jul 2011 21:35:54 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by ietfa.amsl.com (Postfix) with ESMTP id 870661F0C6F for ; Sun, 3 Jul 2011 21:35:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=zhengyli@cisco.com; l=1861; q=dns/txt; s=iport; t=1309754154; x=1310963754; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=mHxMIRu5Pp6Sc3D/sLesAQdIYVACRvxCGIvv6JgytvQ=; b=lJbPNWYGlPQAlIL1s7fIOnQTfVk+bD7nW0jl7oZimunZezK0LYOoZx7g NivuKFEWRYdzHbVX5l5nNSSo2ygVex+DyzNk50qVT8HnyNZmuoX4r1Dj0 PMKir75rUZgQuyS85+gbfAH/+c6sNBtOk6k4YDCMlNikZMWgMjbZftqod E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAFlCEU6rRDoG/2dsb2JhbABPA6d8d64rnQqDQYJ1BIc9inmEeItL X-IronPort-AV: E=Sophos;i="4.65,470,1304294400"; d="scan'208";a="360311697" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-5.cisco.com with ESMTP; 04 Jul 2011 04:35:53 +0000 Received: from [64.104.167.59] ([64.104.167.59]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p644ZpPQ010978; Mon, 4 Jul 2011 04:35:52 GMT User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Mon, 04 Jul 2011 12:35:50 +0800 From: Rockson Li To: Iljitsch van Beijnum Message-ID: Thread-Topic: AUTH cmd and transparent mde In-Reply-To: <5519AAAE-446E-4DF9-B487-ED5CEE72DEC5@muada.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: draft-ietf-behave-ftp64.all@tools.ietf.org, behave@ietf.org Subject: [BEHAVE] AUTH cmd and transparent mde 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, 04 Jul 2011 04:35:55 -0000 Iljitsch, I don't understand why you were saying "whether the ALG goes into transparent mode and whether the server responds positively to AUTH are orthogonal" Sec 9 of RFC2228 has a state diagram showing if a AUTH is rejected with 4yz, 5yz response, ftp would start over and might go as a normal plain user/password authentication, Whereas transparent ALG canot fit. Are you saying you are proposing to use ALGS command to control transparent mode regardless of AUTH command in -11? But I still see the following text in sec 5, is this intentional? "To ensure consistent behavior, as soon as the initial AUTH command is issued by the client, an ALG MUST stop translating commands and responses, and start transparently copying back and forth TCP data sent by the client and the server." Thanks -Rockson On 6/30/11 9:39 PM, "Iljitsch van Beijnum" wrote: >On 30 jun 2011, at 15:34, Rockson Li wrote: > >> On "However, we now also have the ALGS command to explicitly do this so >>I >> guess this is no longer necessary and could be removed. Thoughts, >>anyone?" >> But it's impossible for clients to know whether a ALG has been used in >>the >> session or not. >> Client should be operating transparently in terms FTP64. > >> I think we need to track the response code of AUTH if a final successful >> response is returned from server, we need to get into the the >>transparent >> mode instead of in all the cases. > >No, that wouldn't work because whether the ALG goes into transparent mode >and whether the server responds positively to AUTH are orthogonal. I made >the AUTH less prominent in the new version of the draft, have a look. > >If people want an ALG to be transparent, they can simply use ALGS. If >there's no ALG they get a 50x response, which causes no problems. From iljitsch@muada.com Mon Jul 4 00:29:15 2011 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 5C43D21F86D3 for ; Mon, 4 Jul 2011 00:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.367 X-Spam-Level: X-Spam-Status: No, score=-102.367 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, NO_RELAYS=-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 K8pQlYbj4RFs for ; Mon, 4 Jul 2011 00:29:14 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id 0A41921F86E3 for ; Mon, 4 Jul 2011 00:29:04 -0700 (PDT) Received: from [IPv6:2001:470:1f0b:1289:223:12ff:fe56:36b2] ([IPv6:2001:470:1f0b:1289:223:12ff:fe56:36b2]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id p647TX5C050563 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 4 Jul 2011 09:29:34 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: Date: Mon, 4 Jul 2011 09:28:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Rockson Li X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-behave-ftp64@tools.ietf.org, "behave@ietf.orgWG WG" Subject: Re: [BEHAVE] AUTH cmd and transparent mde (ftp64) 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, 04 Jul 2011 07:29:15 -0000 On 4 jul 2011, at 6:35, Rockson Li wrote: > I don't understand why you were saying "whether the ALG goes into > transparent mode and whether the server responds positively to AUTH = are > orthogonal" The idea was that just the fact that the client issued the AUTH command = was enough to make the ALG become transparent, so a client could issue = AUTH to trigger transparent mode even if it didn't intend to actually = use the AUTH feature towards the server. But this is no longer necessary = as the ALGS command serves this function. > Sec 9 of RFC2228 has a state diagram showing if a AUTH is rejected = with > 4yz, 5yz response, ftp would start over and might go as a normal plain > user/password authentication, > Whereas transparent ALG canot fit. Not sure what you mean by "fit". I don't want to tell implementers of = the ALG to monitor the progression of the AUTH negotiation, this would = add too much complexity IMO. So AUTH -> transparent. If AUTH is rejected = and this leads to problems because the translation is disabled in the = ALG, too bad. > Are you saying you are proposing to use ALGS command to control > transparent mode regardless of AUTH command in -11? Clients should use the ALGS command to make the ALG transparent and use = the AUTH command to negotiate more secure authentication. > But I still see the following text in sec 5, is this intentional? > "To ensure consistent behavior, as > soon as the initial AUTH command is issued by the client, an ALG = MUST > stop translating commands and responses, and start transparently > copying back and forth TCP data sent by the client and the server." I guess this could be a SHOULD now, if implementers want to use more = advanced logic that would be ok. Should I change this? Iljitsch= From jean-philippe.dionne@viagenie.ca Mon Jul 4 07:18:59 2011 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 0DA5F21F8608 for ; Mon, 4 Jul 2011 07:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 tpuePsKneoWg for ; Mon, 4 Jul 2011 07:18:58 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE0D21F85C1 for ; Mon, 4 Jul 2011 07:18:58 -0700 (PDT) Received: from JPD.local (h105.viagenie.ca [206.123.31.105]) by jazz.viagenie.ca (Postfix) with ESMTPSA id E550120DFD for ; Mon, 4 Jul 2011 10:18:52 -0400 (EDT) Message-ID: <4E11CBC8.4010209@viagenie.ca> Date: Mon, 04 Jul 2011 10:18:48 -0400 From: Jean-Philippe Dionne User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: behave@ietf.org Content-Type: multipart/alternative; boundary="------------050801020908070408010900" Subject: [BEHAVE] Fwd: I-D Action: draft-jpdionne-behave-cgn-mib-00.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: Mon, 04 Jul 2011 14:18:59 -0000 This is a multi-part message in MIME format. --------------050801020908070408010900 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, Please have a look at a proposal for a CGN MIB. Your suggestions are welcomed. Regards Jean-Philippe -------- Original Message -------- Subject: I-D Action: draft-jpdionne-behave-cgn-mib-00.txt Date: Sun, 03 Jul 2011 13:13:44 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : CGN Management Information Base (MIB) Author(s) : Jean-Philippe Dionne Marc Blanchet Filename : draft-jpdionne-behave-cgn-mib-00.txt Pages : 10 Date : 2011-07-03 This memo describes the "Carrier Grade NAT" (CGN) Management Information Base (MIB). It is a complement to the NAT-MIB to cope with additional requirements for NAT deployed in large scale networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jpdionne-behave-cgn-mib-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-jpdionne-behave-cgn-mib-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------050801020908070408010900 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

Please have a look at a proposal for a CGN MIB.  Your suggestions are welcomed.

Regards
Jean-Philippe

-------- Original Message --------
Subject: I-D Action: draft-jpdionne-behave-cgn-mib-00.txt
Date: Sun, 03 Jul 2011 13:13:44 -0700
From: internet-drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org 


A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : CGN Management Information Base (MIB)
	Author(s)       : Jean-Philippe Dionne
                          Marc Blanchet
	Filename        : draft-jpdionne-behave-cgn-mib-00.txt
	Pages           : 10
	Date            : 2011-07-03

   This memo describes the &quot;Carrier Grade NAT&quot; (CGN) Management
   Information Base (MIB).  It is a complement to the NAT-MIB to cope
   with additional requirements for NAT deployed in large scale
   networks.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-jpdionne-behave-cgn-mib-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-jpdionne-behave-cgn-mib-00.txt
_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
--------------050801020908070408010900-- From zhengyli@cisco.com Mon Jul 4 20:55:34 2011 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 2742221F8690 for ; Mon, 4 Jul 2011 20:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.098 X-Spam-Level: X-Spam-Status: No, score=-9.098 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_PROLOSTOCK_SYM3=1.63] 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 TTFKlBNXEsR6 for ; Mon, 4 Jul 2011 20:55:33 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 28AEB21F8689 for ; Mon, 4 Jul 2011 20:55:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=zhengyli@cisco.com; l=2833; q=dns/txt; s=iport; t=1309838133; x=1311047733; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=+HeosxGnZFuFAqDXS0+P0cbtAw1rPB9QRxPNgm2WFVE=; b=bQEWamOYs8j/mAExKQ8Wu36JfbEMva9MgISdit5GJAojkLgHyfd2VnGu Nr9lVdaAtue7IVltKmBoKcbbS18YKPBdqha/kvkNwbj4PX4VEwIuU6WAf MfBx6WYKxmKJulwkzvoi0lUTHyz8JIC5VFXNZyci9FPfx9TwW76Ru2xwu E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EADCKEk5Io8UT/2dsb2JhbABQA6d9d646nWWDQYJ1BIc9inmEeItL X-IronPort-AV: E=Sophos;i="4.65,477,1304294400"; d="scan'208";a="40577829" Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-2.cisco.com with ESMTP; 05 Jul 2011 03:55:30 +0000 Received: from [64.104.167.59] ([64.104.167.59]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p653tSKD004891; Tue, 5 Jul 2011 03:55:29 GMT User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Tue, 05 Jul 2011 11:55:26 +0800 From: Rockson Li To: Iljitsch van Beijnum Message-ID: Thread-Topic: AUTH cmd and transparent mde (ftp64) In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: draft-ietf-behave-ftp64@tools.ietf.org, "behave@ietf.orgWG WG" Subject: Re: [BEHAVE] AUTH cmd and transparent mde (ftp64) 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, 05 Jul 2011 03:55:34 -0000 Iljitsch, On "If AUTH is rejected and this leads to problems because the translation is disabled in the ALG, too bad." "Clients should use the ALGS command to make the ALG transparent" Why do you think ftp client can support those ALG specific ALGS command to control the transparent mode? Ftp client might have no awareness of the ALG, I don't think it make any sense to ask end user to change/upgrade the ftp client when they need to traverse ALG. On "I don't want to tell implementers of the ALG to monitor the progression of the AUTH negotiation, this would add too much complexity IMO" Currently, ALG is tracking EPRT/EPSV request and response. I don't think it adds much complexity for one more response. Actually the point is I don't think ALGS is good choice here. Non ALGS-cmd aware ftp client must continue to work, which IMO is critical to the success of this draft. -Rockson On 7/4/11 3:28 PM, "Iljitsch van Beijnum" wrote: >On 4 jul 2011, at 6:35, Rockson Li wrote: > >> I don't understand why you were saying "whether the ALG goes into >> transparent mode and whether the server responds positively to AUTH are >> orthogonal" > >The idea was that just the fact that the client issued the AUTH command >was enough to make the ALG become transparent, so a client could issue >AUTH to trigger transparent mode even if it didn't intend to actually use >the AUTH feature towards the server. But this is no longer necessary as >the ALGS command serves this function. > >> Sec 9 of RFC2228 has a state diagram showing if a AUTH is rejected with >> 4yz, 5yz response, ftp would start over and might go as a normal plain >> user/password authentication, >> Whereas transparent ALG canot fit. > >Not sure what you mean by "fit". I don't want to tell implementers of the >ALG to monitor the progression of the AUTH negotiation, this would add >too much complexity IMO. So AUTH -> transparent. If AUTH is rejected and >this leads to problems because the translation is disabled in the ALG, >too bad. > >> Are you saying you are proposing to use ALGS command to control >> transparent mode regardless of AUTH command in -11? > >Clients should use the ALGS command to make the ALG transparent and use >the AUTH command to negotiate more secure authentication. > >> But I still see the following text in sec 5, is this intentional? > >> "To ensure consistent behavior, as >> soon as the initial AUTH command is issued by the client, an ALG MUST >> stop translating commands and responses, and start transparently >> copying back and forth TCP data sent by the client and the server." > >I guess this could be a SHOULD now, if implementers want to use more >advanced logic that would be ok. > >Should I change this? > >Iljitsch From iljitsch@muada.com Tue Jul 5 04:26:35 2011 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 3FE2D21F8589 for ; Tue, 5 Jul 2011 04:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.581 X-Spam-Level: X-Spam-Status: No, score=-101.581 tagged_above=-999 required=5 tests=[AWL=-0.611, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_PROLOSTOCK_SYM3=1.63, 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 6bdlb7F6-X4z for ; Tue, 5 Jul 2011 04:26:34 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id 9E3C621F8588 for ; Tue, 5 Jul 2011 04:26:34 -0700 (PDT) Received: from [IPv6:2001:470:1f0b:1289:223:12ff:fe56:36b2] ([IPv6:2001:470:1f0b:1289:223:12ff:fe56:36b2]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id p65BR0HZ058919 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 Jul 2011 13:27:01 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: Date: Tue, 5 Jul 2011 13:26:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Rockson Li X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-behave-ftp64@tools.ietf.org, "behave@ietf.orgWG WG" Subject: Re: [BEHAVE] AUTH cmd and transparent mde (ftp64) 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, 05 Jul 2011 11:26:35 -0000 Hi Rockson, On 5 jul 2011, at 5:55, Rockson Li wrote: >> "Clients should use the ALGS command to make the ALG transparent" > Why do you think ftp client can support those ALG specific ALGS = command to > control the transparent mode? > Ftp client might have no awareness of the ALG, I don't think it make = any > sense to ask end user to change/upgrade the ftp client when they need = to > traverse ALG. The purpose of the ALG is to make unmodified FTP clients on an IPv6 = system work with unmodified FTP servers on an IPv4 system. The ALGS command is there to allow users/clients who want more control = over what happens to exert that control. Yes, this means using a client = that allows sending arbitrary commands (command line clients can = typically do that) and possibly some other workarounds, too. But it's = better than being stuck in a situation where an ALG acts in an = undesireable way with no option to do something about that. >> "I don't want to tell implementers of the ALG to monitor the >> progression of the AUTH negotiation, this would add too much = complexity >> IMO" > Currently, ALG is tracking EPRT/EPSV request and response. I don't = think > it adds much complexity for one more response. > Actually the point is I don't think ALGS is good choice here. Non = ALGS-cmd > aware ftp client must continue to work, which IMO is critical to the > success of this draft. Can you think of any situation where normal use cases that work over = IPv6 wouldn't work over NAT64 with the ALG specified here? Iljitsch= From zhengyli@cisco.com Tue Jul 5 22:33:27 2011 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 BEB7B21F8650 for ; Tue, 5 Jul 2011 22:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.072 X-Spam-Level: X-Spam-Status: No, score=-9.072 tagged_above=-999 required=5 tests=[AWL=-0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_PROLOSTOCK_SYM3=1.63] 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 uw7-xDMMWvsn for ; Tue, 5 Jul 2011 22:33:27 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id BA00221F864F for ; Tue, 5 Jul 2011 22:33:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=zhengyli@cisco.com; l=3028; q=dns/txt; s=iport; t=1309930406; x=1311140006; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=bO/v8hH/VlPjFcs2xRH2FkG/lC57pZUbL+3r6qFj9nk=; b=GhgVFPqzO+tI/MXbKuEyOw60+oig/fNm/wJ2oZ5gXR+eTuGhk1dd7JAP D00RsD7u0boHAYUjbJz7MUVPAuAhmGeSA76PCU65BpKW2C6atR6q/Ii/U rfe6LVqFgxhoLi1NSIDndV8u2dr7l8DFJNaVvjeQlR1wVmjRFUC5TA9q+ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAPnyE05Io8US/2dsb2JhbABQA6gOd65CnimDQYJ1BIdEinyEeotP X-IronPort-AV: E=Sophos;i="4.65,484,1304294400"; d="scan'208";a="40772288" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-2.cisco.com with ESMTP; 06 Jul 2011 05:33:24 +0000 Received: from [64.104.167.59] ([64.104.167.59]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p665XMGa032612; Wed, 6 Jul 2011 05:33:23 GMT User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Wed, 06 Jul 2011 13:33:21 +0800 From: Rockson Li To: Iljitsch van Beijnum Message-ID: Thread-Topic: AUTH cmd and transparent mde (ftp64) In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: draft-ietf-behave-ftp64@tools.ietf.org, "behave@ietf.orgWG WG" Subject: Re: [BEHAVE] AUTH cmd and transparent mde (ftp64) 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, 06 Jul 2011 05:33:27 -0000 On "this means using a client that allows sending arbitrary commands (command line clients can typically do that) and possibly some other workarounds, too." I am using a widely used kerberos based cmd-line ftp client http://web.mit.edu/kerberos/www/ I don't find any way I could issue the ALGS command. I guess we need use ftp> quote ALGS DISABLE64 500 'ALGS DISABLE64': command not understood. On "Can you think of any situation where normal use cases that work over IPv6 wouldn't work over NAT64 with the ALG specified here?" In my situation, my ipv6 ftp client first sends "AUTH KERBERO4" and get back 504 "no supported", so it falls back to normal user/password authentication and transfer file between itself and server. However, if I use the same client talking to a IPv4-only ftp server via FTP64 ALG. After I get 504 for "AUTH KERBERO4", ALG start working transparently, and I proceed with user/password authentication, and start the file transfer. But ALG stop translating now. how could the file transfer work in this case? I cannot issue the ALGS command from this client in cli, even I can, How could the end user know that it needs to do it without knowing ALG's presence, the issue of ALG and the action they need take? There's no any clue at all to them. Poor user!!! Thanks Regards -Rockson On 7/5/11 7:26 PM, "Iljitsch van Beijnum" wrote: >Hi Rockson, > >On 5 jul 2011, at 5:55, Rockson Li wrote: > >>> "Clients should use the ALGS command to make the ALG transparent" > >> Why do you think ftp client can support those ALG specific ALGS command >>to >> control the transparent mode? >> Ftp client might have no awareness of the ALG, I don't think it make any >> sense to ask end user to change/upgrade the ftp client when they need >>to >> traverse ALG. > >The purpose of the ALG is to make unmodified FTP clients on an IPv6 >system work with unmodified FTP servers on an IPv4 system. > >The ALGS command is there to allow users/clients who want more control >over what happens to exert that control. Yes, this means using a client >that allows sending arbitrary commands (command line clients can >typically do that) and possibly some other workarounds, too. But it's >better than being stuck in a situation where an ALG acts in an >undesireable way with no option to do something about that. > >>> "I don't want to tell implementers of the ALG to monitor the >>> progression of the AUTH negotiation, this would add too much complexity >>> IMO" > >> Currently, ALG is tracking EPRT/EPSV request and response. I don't think >> it adds much complexity for one more response. >> Actually the point is I don't think ALGS is good choice here. Non >>ALGS-cmd >> aware ftp client must continue to work, which IMO is critical to the >> success of this draft. > >Can you think of any situation where normal use cases that work over IPv6 >wouldn't work over NAT64 with the ALG specified here? > >Iljitsch From iljitsch@muada.com Wed Jul 6 01:49:17 2011 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 D4EAF21F871E for ; Wed, 6 Jul 2011 01:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.328 X-Spam-Level: X-Spam-Status: No, score=-102.328 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, NO_RELAYS=-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 LbSh+VOs5Z9L for ; Wed, 6 Jul 2011 01:49:17 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id 13EA921F8703 for ; Wed, 6 Jul 2011 01:49:16 -0700 (PDT) Received: from [IPv6:2001:720:410:100f:223:32ff:fec4:ba94] ([IPv6:2001:720:410:100f:223:32ff:fec4:ba94]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id p668nhoC065504 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 6 Jul 2011 10:49:44 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: Date: Wed, 6 Jul 2011 10:49:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <42628B88-3CFF-49D6-822B-7C249A9C50D3@muada.com> References: To: Rockson Li X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-behave-ftp64@tools.ietf.org, "behave@ietf.orgWG WG" Subject: Re: [BEHAVE] AUTH cmd and transparent mde (ftp64) 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, 06 Jul 2011 08:49:17 -0000 On 6 jul 2011, at 7:33, Rockson Li wrote: > I don't find any way I could issue the ALGS command. I guess we need = use > ftp> quote ALGS DISABLE64 > 500 'ALGS DISABLE64': command not understood. Exactly. > In my situation, my ipv6 ftp client first sends "AUTH KERBERO4" and = get > back 504 "no supported", > so it falls back to normal user/password authentication and transfer = file > between itself and server. Is this something the client always tries to do automatically? I could add this to the draft: The ALG SHOULD ignore the AUTH command and not go into transparent mode = if the server response is in the 4xx or 5xx ranges. Would that address your issue?= From xiaohong.deng@orange-ftgroup.com Wed Jul 6 02:53:39 2011 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 6BD0F21F860A; Wed, 6 Jul 2011 02:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.602 X-Spam-Level: X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[AWL=0.762, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] 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 djlJ4zN0Dw3Q; Wed, 6 Jul 2011 02:53:38 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 697EF21F86BE; Wed, 6 Jul 2011 02:53:38 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9F80EFC4003; Wed, 6 Jul 2011 11:53:32 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 8FFB0FC4001; Wed, 6 Jul 2011 11:53:32 +0200 (CEST) Received: from ch-mailsrv.rd.francetelecom.fr ([10.193.250.27]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Jul 2011 11:53:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC3BC2.8E7C6ECA" Date: Wed, 6 Jul 2011 17:53:28 +0800 Message-ID: <0962B0BEF842A24191AD9BE41A8DD2FC018698AC@ch-mailsrv.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New draft: draft-zheng-mif-apps-test-00 Thread-Index: Acw7wo5Sa/zBx7J6SFmBxSnO2ikCAQ== From: To: X-OriginalArrivalTime: 06 Jul 2011 09:53:31.0999 (UTC) FILETIME=[90720EF0:01CC3BC2] Cc: softwires@ietf.org, int-area@ietf.org, v6ops@ietf.org, behave@ietf.org Subject: [BEHAVE] New draft: draft-zheng-mif-apps-test-00 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, 06 Jul 2011 09:53:39 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC3BC2.8E7C6ECA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all, =20 A new draft describing applications behaviors dealing with multiple interface issues in the IPv6 transition context has been submitted. In this draft, DS-Lite, AplusP, NAT64 and their combinations with IPv6 provisioning have been tested and suggestions are therefore stated according to the test results. http://tools.ietf.org/id/draft-zheng-mif-apps-test-00.txt =20 =20 The Abstract of this I-D: =20 With the development of IPv6 and deployment of transition solutions, more and more hosts can access Internet with dual stack by multi-interface and applications behaviors are worth to be concerned under this environment. This memo describes the test results of some well-known applications in different scenarios under MIF environment and provides an analysis and suggestions to develop and deploy under MIF environment. =20 Comments are very much appreciated if it's something of your interest. =20 Cheers, Xiaohong =20 open source PCP Client, open source A+P http://opensourcev6transtechnologies.weebly.com/ =20 =20 ------_=_NextPart_001_01CC3BC2.8E7C6ECA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello=20 all,

 

A new draft describing applications = behaviors=20 dealing with multiple interface issues in the IPv6 transition context = has been=20 submitted. In this draft, DS-Lite, AplusP, NAT64 and their combinations = with=20 IPv6 provisioning have been tested and suggestions are therefore stated=20 according to the test results.

http://tools.ietf.org/id/draft-zheng-mif-apps-test-00.txt=

 

The Abstract of this = I-D:

 

With the development of IPv6 and = deployment of=20 transition solutions, more and more hosts can access Internet with dual = stack by=20 multi-interface and applications behaviors are worth to be concerned = under   this environment. This = memo=20 describes the test results of some well-known applications in different=20 scenarios under MIF environment and provides an analysis and suggestions = to=20 develop and deploy under MIF environment.

 

Comments are very much appreciated if = it's=20 something of your interest.

 

Cheers,

Xiaohong

 
open source PCP = Client,
open source = A+P
http://opensour= cev6transtechnologies.weebly.com/
 
 
------_=_NextPart_001_01CC3BC2.8E7C6ECA-- From zhengyli@cisco.com Wed Jul 6 23:58:02 2011 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 8261D21F87A7 for ; Wed, 6 Jul 2011 23:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.87 X-Spam-Level: X-Spam-Status: No, score=-9.87 tagged_above=-999 required=5 tests=[AWL=0.729, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 VkzOhNqirxLT for ; Wed, 6 Jul 2011 23:58:01 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id EAA2D21F8625 for ; Wed, 6 Jul 2011 23:58:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=zhengyli@cisco.com; l=19576; q=dns/txt; s=iport; t=1310021881; x=1311231481; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=utuyOf9jVNe+yk10l138SGzoJTsJEBHh02xEv0NVwjg=; b=CHqsmjVsIXAoL6HPZNAh4jdExpuQ+lhe4ZHeQLNL9nvBzIyCuSn0NHRG 4cqfYNYK338sB/Ely5QLahEZcpIWGqgYxPWWkPjtq3CdIBKY62U8YFY21 d56IZzcvn+DuYxicATWbdZHs3I6/43gXA7L6YGEZ3pxaTljWIVz6BzemX 0=; X-Files: ftp.pcap : 12229 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAG9YFU5Io8UT/2dsb2JhbABTqBd3rnmddYY3BIdHhhSEa4R9i1E X-IronPort-AV: E=Sophos;i="4.65,491,1304294400"; d="pcap'?scan'208";a="40967683" Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-2.cisco.com with ESMTP; 07 Jul 2011 06:57:59 +0000 Received: from [64.104.169.76] ([64.104.169.76]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p676vtUt015214; Thu, 7 Jul 2011 06:57:56 GMT User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Thu, 07 Jul 2011 14:57:53 +0800 From: Rockson Li To: Iljitsch van Beijnum Message-ID: Thread-Topic: AUTH cmd and transparent mde (ftp64) In-Reply-To: <42628B88-3CFF-49D6-822B-7C249A9C50D3@muada.com> Mime-version: 1.0 Content-type: multipart/mixed; boundary="B_3392895476_2235321" Cc: draft-ietf-behave-ftp64@tools.ietf.org, "behave@ietf.orgWG WG" Subject: Re: [BEHAVE] AUTH cmd and transparent mde (ftp64) 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: Thu, 07 Jul 2011 06:58:02 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3392895476_2235321 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit > >Is this something the client always tries to do automatically? Yes,client would do it automatically, wireshark capture is attached for your reference. >I could add this to the draft: > >The ALG SHOULD ignore the AUTH command and not go into transparent mode >if the server response is in the 4xx or 5xx ranges. > >Would that address your issue? Yes, that would address most of issues. Can we also cover 4yz,5yz for ADAT command here? As said in sec 9 of RFC2228, the authentication procedure would restart from scratch from 4yx/5yz for either AUTH or ADAT ,------------------, USER __\| Unauthenticated |_________\ | /| (new connection) | /| | `------------------' | | | | | | AUTH | | V | | / \ | | 4yz,5yz / \ 234 | |<--------< >------------->. | | \ / | | | \_/ | | | | | | | | 334 | | | V | | | ,--------------------, | | | | Need Security Data |<--. | | | `--------------------' | | | | | | | | | | ADAT | | | | V | | | | / \ | | | | 4yz,5yz / \ 335 | | | `<--------< >-----------' | | \ / | | \_/ | | | | | | 235 | | V | | ,---------------. | | ,--->| Authenticated |<--------' | After the client and server | `---------------' | have completed authenti- | | | cation, command must be | | USER | integrity-protected if | | | integrity is available. The | |<-------------------' CCC command may be issued to | V relax this restriction. --B_3392895476_2235321 Content-type: application/octet-stream; name="ftp.pcap" Content-disposition: attachment; filename="ftp.pcap" Content-transfer-encoding: base64 obLD1AACAAQAAAAAAAAAAAAA//8AAAABThPpkQAJ6SwAAADCAAAAwgAADAesAAAUT1A/KggA RQAAtB76QAA8BgAACkoxGApKDBQAFm+tB5m60MgNooqAGMLUAAAAAAEBCAoNaUEeyiet372e sQwLs0N5bf9+cqcFHDMZl99sZl1nwx2sQkGnSzubqVfQm5ZVLyItn5IB+tTRQiJeG4elFzOE pbzV25HLr9PanAGOiRzJbaX20qGkNZQAppogarilTj+5r4zNyN5+lC43ZHpp3bx9K/Lmeyyd ogig4FHkGLmcdAw57fBmDV1LThPpkQAJ6s8AAABCAAAAQgAUT1A/KgATX++ZAAgARQAANImx QAA9BmJTCkoMFApKMRhvrQAWyA2iigeZu1CAEAD3wCYAAAEBCArKJ63rDWlBHk4T6ZQACMyB AAAAlgAAAJYAFE9QPyoAE1/vmQAIAEUAAIgVkkAAPQbWHgpKDBQKSjEYF4KkKwU4YbJ4n788 UBgFuNLSAAAcAE2hAGAC5AAAAKz9zTPbAGzf/wAAAAAYbN//QdkUCBwATaEAYALkAAAAtv3N M9sAbN//AAAAABhs3/9B2RQIEmxNoQBgAuQAYALkAGzf/zTsSgho5lcIOGzf/xBs3/9OE+mU AAjMyQAAAJYAAACWABRPUD8qABNf75kACABFAACIvxpAAD0GLJYKSgwUCkoxGBeCqB5/czqb bzN6k1AYBauILgAAHADqsQMgAuQAAACs/c0z2wBs3/8AAAAAGGzf/0HZFAgcAOqxAyAC5AAA ALb9zTPbAGzf/wAAAAAYbN//QdkUCBJs6rEDIALkAyAC5ACVVQg4bN//wFszAEChQABQlVUI ThPplAAIzOQAAACWAAAAlgAUT1A/KgATX++ZAAgARQAAiDjwQAA9BrLACkoMFApKMRgXgotl SRIqRybhpv9QGAXC1KkAABwAxXEDoALkAAAArP3NM9sAbN//AAAAABhs3/9B2RQIHADFcQOg AuQAAAC2/c0z2wBs3/8AAAAAGGzf/0HZFAgSbMVxA6AC5AOgAuQAbN//NOxKCGjmVwg4bN// EGzf/04T6ZQACmC7AAAANgAAADYAAAwHrAAAFE9QPyoIAEUAACge+0AAQAYAAApKMRgKSgwU qB4Xgm8zepN/czr7UBDEkAAAAABOE+mUAApgwwAAADYAAAA2AAAMB6wAABRPUD8qCABFAAAo Hv1AAEAGAAAKSjEYCkoMFKQrF4J4n788BThiElAQxJAAAAAAThPplAAKYMcAAAA2AAAANgAA DAesAAAUT1A/KggARQAAKB78QABABgAACkoxGApKDBSLZReCJuGm/0kSKqdQEMSQAAAAAE4T 6Z4ADv1GAAAASgAAAEoAFE9QPyoAE1/vmQAIAEUAADxHLEAAPQak0ApKDBQKSjEY2NUAFTO8 pSwAAAAAoAIVQINoAAACBAVQBAIICson4gAAAAAAAQMDB04T6Z4ADv3SAAAATgAAAE4AAAwH rAAAFE9QPyoIAEUAAEAe/kAAPAYAAApKMRgKSgwUABXY1WpWSsYzvKUtsBLC1AAAAAABAQgK DWlGVMon4gACBAW0AQMDAAEBBAJOE+meAA7/NAAAAEIAAABCABRPUD8qABNf75kACABFAAA0 Ry1AAD0GpNcKSgwUCkoxGNjVABUzvKUtalZKx4AQACu9+gAAAQEICson4gANaUZUThPpngAP PAsAAABkAAAAZAAADAesAAAUT1A/KggARQAAVh7/QAA8BgAACkoxGApKDBQAFdjValZKxzO8 pS2AGMLUAAAAAAEBCAoNaUZVyifiADIyMCBzaC12MjQwLXFpIEZUUCBzZXJ2ZXIgcmVhZHku DQpOE+meAA89rwAAAEIAAABCABRPUD8qABNf75kACABFAAA0Ry5AAD0GpNYKSgwUCkoxGNjV ABUzvKUtalZK6YAQACu9xwAAAQEICson4hANaUZVThPpngAPPdUAAABPAAAATwAUT1A/KgAT X++ZAAgARQAAQUcvQAA9BqTICkoMFApKMRjY1QAVM7ylLWpWSumAGAArIB0AAAEBCArKJ+IQ DWlGVUFVVEggR1NTQVBJDQpOE+meAA8+CwAAAEIAAABCAAAMB6wAABRPUD8qCABFAAA0HwBA ADwGAAAKSjEYCkoMFAAV2NVqVkrpM7ylOoAQwtQAAAAAAQEICg1pRlXKJ+IQThPpngAPPosA AABwAAAAcAAADAesAAAUT1A/KggARQAAYh8BQAA8BgAACkoxGApKDBQAFdjValZK6TO8pTqA GMLUAAAAAAEBCAoNaUZVyifiEDMzNCBVc2luZyBBVVRIIHR5cGUgR1NTQVBJOyBBREFUIG11 c3QgZm9sbG93DQpOE+mfAACa1wAAAEIAAABCABRPUD8qABNf75kACABFAAA0RzBAAD0GpNQK SgwUCkoxGNjVABUzvKU6alZLF4AQACu9YwAAAQEICson4jkNaUZVThPpnwABBQ4AAABUAAAA VAAUT1A/KgATX++ZAAgARQAARkcxQAA9BqTBCkoMFApKMRjY1QAVM7ylOmpWSxeAGAArdsEA AAEBCArKJ+JUDWlGVUFVVEggS0VSQkVST1NfVjQNCk4T6Z8AAQVYAAAAQgAAAEIAAAwHrAAA FE9QPyoIAEUAADQfAkAAPAYAAApKMRgKSgwUABXY1WpWSxczvKVMgBDC1AAAAAABAQgKDWlG XMon4lROE+mfAAEF+gAAAGcAAABnAAAMB6wAABRPUD8qCABFAABZHwNAADwGAAAKSjEYCkoM FAAV2NVqVksXM7ylTIAYwtQAAAAAAQEICg1pRlzKJ+JUNTA0IEFVVEggS0VSQkVST1NfVjQg bm90IHN1cHBvcnRlZC4NCk4T6Z8AAQd9AAAAQgAAAEIAFE9QPyoAE1/vmQAIAEUAADRHMkAA PQak0gpKDBQKSjEY2NUAFTO8pUxqVks8gBAAK70JAAABAQgKyifiVQ1pRlxOE+mgAA6vLwAA AE8AAABPABRPUD8qABNf75kACABFAABBRzNAAD0GpMQKSgwUCkoxGNjVABUzvKVMalZLPIAY ACuhlgAAAQEICson6bwNaUZcVVNFUiBtZ2N1c3INCk4T6aAADrMgAAAAZQAAAGUAAAwHrAAA FE9QPyoIAEUAAFcfBEAAPAYAAApKMRgKSgwUABXY1WpWSzwzvKVZgBjC1AAAAAABAQgKDWlH Gson6bwzMzEgUGFzc3dvcmQgcmVxdWlyZWQgZm9yIG1nY3Vzci4NCk4T6aAADrV/AAAAQgAA AEIAFE9QPyoAE1/vmQAIAEUAADRHNEAAPQak0ApKDBQKSjEY2NUAFTO8pVlqVktfgBAAK7Sz AAABAQgKyifpvQ1pRxpOE+miAAEnfwAAAE8AAABPABRPUD8qABNf75kACABFAABBRzVAAD0G pMIKSgwUCkoxGNjVABUzvKVZalZLX4AYACuTYQAAAQEICson7hQNaUcaUEFTUyBtZ2N1c3IN Ck4T6aIAAc/mAAAAXgAAAF4AAAwHrAAAFE9QPyoIAEUAAFAfBUAAPAYAAApKMRgKSgwUABXY 1WpWS18zvKVmgBjC1AAAAAABAQgKDWlHjcon7hQyMzAgVXNlciBtZ2N1c3IgbG9nZ2VkIGlu Lg0KThPpogAB13oAAABCAAAAQgAUT1A/KgATX++ZAAgARQAANEc2QAA9BqTOCkoMFApKMRjY 1QAVM7ylZmpWS3uAEAArr5MAAAEBCArKJ+5BDWlHjU4T6aIAAdeQAAAASAAAAEgAFE9QPyoA E1/vmQAIAEUAADpHN0AAPQakxwpKDBQKSjEY2NUAFTO8pWZqVkt7gBgAK/vNAAABAQgKyifu QQ1pR41TWVNUDQpOE+miAAHX9AAAAGQAAABkAAAMB6wAABRPUD8qCABFAABWHwZAADwGAAAK SjEYCkoMFAAV2NVqVkt7M7ylbIAYwtQAAAAAAQEICg1pR47KJ+5BMjE1IFVOSVggVHlwZTog TDggVmVyc2lvbjogU1VOT1MNCk4T6aIAAnjWAAAAQgAAAEIAFE9QPyoAE1/vmQAIAEUAADRH OEAAPQakzApKDBQKSjEY2NUAFTO8pWxqVkudgBAAK69AAAABAQgKyifuaw1pR45OE+mqAAzX 0AAAAEgAAABIABRPUD8qABNf75kACABFAAA6RzlAAD0GpMUKSgwUCkoxGNjVABUzvKVsalZL nYAYACvllQAAAQEICsooEFQNaUeOUVVJVA0KThPpqgAM2McAAABwAAAAcAAADAesAAAUT1A/ KggARQAAYh8HQAA8BgAACkoxGApKDBQAFdjValZLnTO8pXKAGMLUAAAAAAEBCAoNaUr2yigQ VDIyMS1Zb3UgaGF2ZSB0cmFuc2ZlcnJlZCAwIGJ5dGVzIGluIDAgZmlsZXMuDQpOE+mqAAza NQAAAEIAAABCABRPUD8qABNf75kACABFAAA0RzpAAD0GpMoKSgwUCkoxGNjVABUzvKVyalZL y4AQACuJuwAAAQEICsooEFQNaUr2ThPpqgAM2oIAAADKAAAAygAADAesAAAUT1A/KggARQAA vB8IQAA8BgAACkoxGApKDBQAFdjValZLyzO8pXKAGMLUAAAAAAEBCAoNaUr2yigQVDIyMS1U b3RhbCB0cmFmZmljIGZvciB0aGlzIHNlc3Npb24gd2FzIDMxNSBieXRlcyBpbiAwIHRyYW5z ZmVycy4NCjIyMS1UaGFuayB5b3UgZm9yIHVzaW5nIHRoZSBGVFAgc2VydmljZSBvbiBzaC12 MjQwLXFpLg0KMjIxIEdvb2RieWUuDQpOE+mqAAzcKAAAAEIAAABCABRPUD8qABNf75kACABF AAA0RztAAD0GpMkKSgwUCkoxGNjVABUzvKVyalZMU4AQADOJKgAAAQEICsooEFUNaUr2ThPp qgAM3Z8AAABCAAAAQgAUT1A/KgATX++ZAAgARQAANEc8QAA9BqTICkoMFApKMRjY1QAVM7yl cmpWTFOAEQAziSkAAAEBCArKKBBVDWlK9k4T6aoADN3KAAAAQgAAAEIAAAwHrAAAFE9QPyoI AEUAADQfCUAAPAYAAApKMRgKSgwUABXY1WpWTFMzvKVzgBDC1AAAAAABAQgKDWlK9sooEFVO E+mqAAzfRQAAAEIAAABCAAAMB6wAABRPUD8qCABFAAA0HwpAADwGAAAKSjEYCkoMFAAV2NVq VkxTM7ylc4ARwtQAAAAAAQEICg1pSvbKKBBVThPpqgAM4JAAAABCAAAAQgAUT1A/KgATX++Z AAgARQAANAAAQAA9BuwECkoMFApKMRjY1QAVM7ylc2pWTFSAEAAziScAAAEBCArKKBBWDWlK 9k4T6b4ACLAaAAAAdgAAAHYAFE9QPyoAE1/vmQAIAEUAAGi/G0AAPQYstQpKDBQKSjEYF4Ko Hn9zOvtvM3qTUBgFq4ESAAAcP+qxAyAC5AAAAKz9zdflAGvf//Br3/8BAAAARGzf/xw/6rED IALkAAAAtv3N1+UAa9//8Gvf/wEAAABEbN//ThPpvgAIsgUAAAB2AAAAdgAUT1A/KgATX++Z AAgARQAAaBWTQAA9BtY9CkoMFApKMRgXgqQrBThiEnifvzxQGAW4yDAAABz7TaEAYALkAAAA rP3N1+UAa9//8Gvf/wEAAABEbN//HPtNoQBgAuQAAAC2/c3X5QBr3//wa9//AQAAAERs3/9O E+m+AAiyggAAALYAAAC2ABRPUD8qABNf75kACABFAACovxxAAD0GLHQKSgwUCkoxGBeCqB5/ czs7bzN6k1AYBauP5gAAE2vqsQMgAuQDIALkAGzf//TBZgjA1hQI9MFmCFBs3/8PAOqxAyAC 6gEDtwOIhWQIGJZ1CPEYMwCYad//AAAAAAyq6rEDIALqBDMAKwA5ACkAAGkI8RgzAJCqaQji AwAADNzqsQMgAugAAAArABAAKQAAiAjxGDMAcNyICOIDAABOE+m+AAiy2wAAADYAAAA2AAAM B6wAABRPUD8qCABFAAAoHwtAAEAGAAAKSjEYCkoMFKgeF4JvM3qTf3M7u1AQxJAAAAAAThPp vgAIs4cAAALGAAACxgAADAesAAAUT1A/KggARQACuB8MQABABgAACkoxGApKDBSoHheCbzN6 k39zO7tQGMSQAAAAADgBAAUDIAAJAAAADAAAzlkAAAAATAcABgMgAuoDIAAJBDIAKSAgICAg ICAETAcABgMgAuoDIAAJBDIANyAgICAgICAJTAcABgMgAuoDIAAJBDIARSAgICAgICBZTAcA BgMgAuoDIAAJBDIAUyAgICAgICAEOCAABQMgAAkAAAAMAAAAAAAA+ABMAQAFAyAC6gMgAAkA IgIhcHIgcEpyAAUDIALqAyAACQAjAiEBAHAAOHAABAMgAAkAAAAEAAAP4kMgAAUDIALqAyAA CQAiAhYABwANQiAACwMgAugDIAAPAAAAAAAPAAAAAAABAA4AAQAAAAIAAALJAAEAAgABAshC IAALAyAC6AMgAA4AAQLJAA8CyQACAsgADwLIAA8AAQAPAskADgACAA4CyT4gAAcDIAR0AyAC 6AMgACEAAAAAAAIBigAMAD5GIAATAyAC6AMgAA4AAgAMAAIAAQACAA0AAQABAAMACgACAAIA BAAIAAIAAgAFAAYAAgACAAYABAACAAIABwACAAIAAQAHAAMAAQABRiAAEQMgAugDIAAPAAMA DQABAAEABAAMAAoAAgALAAoAAgACAAoACAACAAIACQAGAAIAAgAIAAQAAgACAAgAAwABAAFG IAAJAyAC6AMgACEABQAKAAYAAgAGAAgABAACAAcABgACAAJGIAAPAyAC6AMgAA4ADAK8AAIA AQACArwACgACAAMCvgACAAIABALAAAIAAgAFAsIAAgACAAYCxAACAAJGIgANAyAC6AMgAA8A DAK9AAIAAQALAr4AAgACAAoCwAACAAIACQLCAAIAAgAIAsQAAgACRmYACQMgAugDIAAhAAUC vgAGAAIABgLAAAQAAgAHAsIAAgACThPpvgAItPYAAACWAAAAlgAUT1A/KgATX++ZAAgARQAA iBWUQAA9BtYcCkoMFApKMRgXgqQrBThiUnifvzxQGAW4r9cAABNrTaEAYALkAGAC5ABs3/9E 41kIwNYUCETjWQhQbN//DwBNoQBgAuoBA7cD6LiCCJgfegjxGDMAmGnf/wAAAAAME02hAGAC 6gAAAF0ADwI3AACCCPEYMwAouYII4gMAAE4T6b4ACLUbAAAAdgAAAHYAFE9QPyoAE1/vmQAI AEUAAGg48UAAPQay3wpKDBQKSjEYF4KLZUkSKqcm4ab/UBgFwkmMAAAcYMVxA6AC5AAAAKz9 zdfmAGvf//Br3/8BAAAARGzf/xxgxXEDoALkAAAAtv3N1+YAa9//8Gvf/wEAAABEbN//ThPp vgAItTwAAAA2AAAANgAADAesAAAUT1A/KggARQAAKB8NQABABgAACkoxGApKDBSkKxeCeJ+/ PAU4YrJQEMSQAAAAAE4T6b4ACLWdAAAEMgAABDIAAAwHrAAAFE9QPyoIAEUABCQfDkAAQAYA AApKMRgKSgwUpCsXgnifvzwFOGKyUBjEkAAAAAA4AQAEAGAACQAAAAQAAM5ZTAIABQBgAuoA YAAJAAIAYSAgIGFMAgAFAGAC6gBgAAkAAgBvICAgBUwCAAUAYALqAGAACQACAH0gICAFTAIA BQBgAuoAYAAJAAIAiyAgIAVMAgAFAGAC6gBgAAkAAgCZICAgBUwCAAUAYALqAGAACQACAKcp OyAFTAIABQBgAuoAYAAJAAIAtSAgIAQ4YAAEAGAACQAAAAQAAIT/TAIABQBgAuoAYAAJAAIA wyMkYQQ4YAAEAGAACQAAAAQAAM5ZTAIABQBgAuoAYAAJAAIA0SAgIAQ4YAAEAGAACQAAAAQA AEf/TAIABQBgAuoAYAAJAAIA3yR1LQU4YAAEAGAACQAAAAQAAM5ZTAIABQBgAuoAYAAJAAIA 7SAgIF1MAgAFAGAC6gBgAAkAAgD7ICAga0wCAAUAYALqAGAACQACAQkgICB5TAIABQBgAuoA YAAJAAIBFyAgIIdMAgAFAGAC6gBgAAkAAgElICAglUwCAAUAYALqAGAACQACATMgICCjTAIA BQBgAuoAYAAJAAIBQSAgILFMAgAFAGAC6gBgAAkAAgFPICAgv0wCAAUAYALqAGAACQACAV0g ICDNTAIABQBgAuoAYAAJAAIBayAgINtMAgAFAGAC6gBgAAkAAgF5ICAg6UwCAAUAYALqAGAA CQACAYcgICD3TAIABQBgAuoAYAAJAAIBlSAgIAVMAgAFAGAC6gBgAAkAAgGjICAgE0wCAAUA YALqAGAACQACAbEgICAhTAIABQBgAuoAYAAJAAIBvyAgIC9MAgAFAGAC6gBgAAkAAgHNICAg PUwCAAUAYALqAGAACQACAdsgICBLTAIABQBgAuoAYAAJAAIB6SAgIFlMAgAFAGAC6gBgAAkA AgH3ICAgZ0wCAAUAYALqAGAACQACAgUgICD/TAIABQBgAuoAYAAJAAICEyAgIARMAgAFAGAC 6gBgAAkAAgIhICAgBUwCAAUAYALqAGAACQACAi8gICAFTAIABQBgAuoAYAAJAAICPSAgIAVM AgAFAGAC6gBgAAkAAgJLICAgBUwCAAUAYALqAGAACQACAlkpOyAFTAIABQBgAuoAYAAJAAIC ZyAgIAU4YAAEAGAACQAAAAQAAIT/TAIABQBgAuoAYAAJAAICdSMkYQVMAgAFAGAC6gBgAAkA AgKDIyAgBDhgAAQAYAAJAAAABAAAzllMAgAFAGAC6gBgAAkAAgKRInNjBDhgAAQAYAAJAAAA BAAA/PNMAQAFAGAC6gBgAAkA8gIFMQcAAzgBAAQAYAAJAAAABAAAD+JDAwAFAGAC6gBgAAkA 8gH6AAcADT0AAAQAYALqAAAAAAACAABOE+m+AAi3YwAAADwAAAA8ABRPUD8qABNf75kACABF AAAoFZVAAD0G1nsKSgwUCkoxGBeCpCsFOGKyeJ/DOFAQBbf47QAAAAAAAAAAThPpvgAIuVoA AABWAAAAVgAUT1A/KgATX++ZAAgARQAASBWWQAA9BtZaCkoMFApKMRgXgqQrBThisnifwzhQ GAW3XYQAAAy5TaEAYALqAA8AXQATAjcAAIII8RgzADC5ggjiAwAAThPpvgAIuW0AAAB2AAAA dgAUT1A/KgATX++ZAAgARQAAaL8dQAA9BiyzCkoMFApKMRgXgqgef3M7u28zfSNQGAWr/FgA AAzc6sQDIALqAAAAKwQzACkAAQAACBSHCAMAAABEwyIIDNzqxAMgAuoAAABUABsChgAAAAAI FIcIAwAAAETDIghOE+m+AAi5fwAAAJYAAACWABRPUD8qABNf75kACABFAACIOPJAAD0Gsr4K SgwUCkoxGBeCi2VJEirnJuGm/1AYBcKvQwAAE2vFcQOgAuQDoALkAGzf/4y8UAjA1hQIjLxQ CFBs3/8PbcVxA6AC6gEDtwPouIIIGJZ1CPEYMwCYad//AAAAAAy5xXEDoALqAAAA4AAwAcIA AIII8RgzADC5ggjiAwAAThPpvgAIuaAAAAA2AAAANgAADAesAAAUT1A/KggARQAAKB8PQABA BgAACkoxGApKDBSLZReCJuGm/0kSK0dQEMSQAAAAAE4T6b4ACLnUAAAEIgAABCIAAAwHrAAA FE9QPyoIAEUABBQfEEAAQAYAAApKMRgKSgwUpCsXgnifwzgFOGLSUBjEkAAAAAA4AQAEAGAA CQAAAAQAAM5ZTAMABQBgAuoAYAAJAAoAYSAgIGFMAwAFAGAC6gBgAAkACgBvICAgBUwDAAUA YALqAGAACQAKAH0gICAFTAMABQBgAuoAYAAJAAoAiyAgIAVMAwAFAGAC6gBgAAkACgCZICAg BUwDAAUAYALqAGAACQAKAKc7ICAFTAMABQBgAuoAYAAJAAoAtSAgIAQ4YAAEAGAACQAAAAQA AIT/TAMABQBgAuoAYAAJAAoAwyR1YQQ4YAAEAGAACQAAAAQAAM5ZTAMABQBgAuoAYAAJAAoA 0SAgIAQ4YAAEAGAACQAAAAQAAEf/TAMABQBgAuoAYAAJAAoA33VhLQU4YAAEAGAACQAAAAQA AM5ZTAMABQBgAuoAYAAJAAoA7SAgIF1MAwAFAGAC6gBgAAkACgD7ICAga0wDAAUAYALqAGAA CQAKAQkgICB5TAMABQBgAuoAYAAJAAoBFyAgIIdMAwAFAGAC6gBgAAkACgElICAglUwDAAUA YALqAGAACQAKATMgICCjTAMABQBgAuoAYAAJAAoBQSAgILFMAwAFAGAC6gBgAAkACgFPICAg v0wDAAUAYALqAGAACQAKAV0gICDNTAMABQBgAuoAYAAJAAoBayAgINtMAwAFAGAC6gBgAAkA CgF5ICAg6UwDAAUAYALqAGAACQAKAYcgICD3TAMABQBgAuoAYAAJAAoBlSAgIAVMAwAFAGAC 6gBgAAkACgGjICAgE0wDAAUAYALqAGAACQAKAbEgICAhTAMABQBgAuoAYAAJAAoBvyAgIC9M AwAFAGAC6gBgAAkACgHNICAgPUwDAAUAYALqAGAACQAKAdsgICBLTAMABQBgAuoAYAAJAAoB 6SAgIFlMAwAFAGAC6gBgAAkACgH3ICAgZ0wDAAUAYALqAGAACQAKAgUgICD/TAMABQBgAuoA YAAJAAoCEyAgIARMAwAFAGAC6gBgAAkACgIhICAgBUwDAAUAYALqAGAACQAKAi8gICAFTAMA BQBgAuoAYAAJAAoCPSAgIAVMAwAFAGAC6gBgAAkACgJLICAgBUwDAAUAYALqAGAACQAKAlk7 ICAFTAMABQBgAuoAYAAJAAoCZyAgIAU4YAAEAGAACQAAAAQAAIT/TAMABQBgAuoAYAAJAAoC dSR1YQVMAwAFAGAC6gBgAAkACgKDICAgBDhgAAQAYAAJAAAABAAAzllMAwAFAGAC6gBgAAkA CgKRc2JjBDhgAAQAYAAJAAAABAAA/PNMAQAFAGAC6gBgAAkA8gIFMQcAAzgBAAQAYAAJAAAA BAAAD+JDAwAFAGAC6gBgAAkA8gH6AAcADU4T6b4ACLpVAAAEmgAABJoAAAwHrAAAFE9QPyoI AEUABIwfEUAAQAYAAApKMRgKSgwUi2UXgibhpv9JEitHUBjEkAAAAAA4AQAEA6AACQAAAAQA AM5ZTAYABgOgAuoDoAAJAAIA3yAgICAgICAgTAYABgOgAuoDoAAJAAIA7SAgICAgICAgTAYA BgOgAuoDoAAJAAIA+yAgICAgICAgTAYABgOgAuoDoAAJAAIBCSAgICAgICAgTAYABgOgAuoD oAAJAAIBFyAgICAgICAgTAYABgOgAuoDoAAJAAIBJSAgICAgICAgTAYABgOgAuoDoAAJAAIB MyAgICAgICAgTAYABgOgAuoDoAAJAAIBQSAgICAgICAgTAYABgOgAuoDoAAJAAIBTyAgICAg ICAgTAYABgOgAuoDoAAJAAIBXSAgICAgICAgTAYABgOgAuoDoAAJAAIBayAgICB9ICAgTAYA BgOgAuoDoAAJAAIBeSAgICAgICAgTAQABQOgAuoDoAAJAAIBhyAgICA4IAAEA6AACQAAAAQA AP/gTAIABQOgAuoDoAAJACIBh2lmAYc4ZgAEA6AACQAAAAQAAM5ZTAYABgOgAuoDoAAJAAIB lSAgICAgICAgTAYABgOgAuoDoAAJAAIBoyAgICAgICAgTAYABgOgAuoDoAAJAAIBsSAgICAg ICAgTAYABgOgAuoDoAAJAAIBvyAgICAgICAgTAYABgOgAuoDoAAJAAIBzSAgICAgICAgTAUA BgOgAuoDoAAJAAIB2yAgICB9ICAgOKAABAOgAAkAAAAEAAD/4EwBAAUDoALqA6AACQAqAdtl KgHbOKAABAOgAAkAAAAEAADOWUwGAAYDoALqA6AACQACAekgICAgICAgIEwEAAUDoALqA6AA CQACAfcgICAgOCAABAOgAAkAAAAIAAAEUUwBAAUDoALqA6AACQAiAfd9IgH3OKAABAOgAAkA AAAIAAAAAEwBAAUDoALqA6AACQAqAfcgKgH3TAYABgOgAuoDoAAJAAICBSAgICAgICAgTAQA BQOgAuoDoAAJAAICEyAgICA4IAAEA6AACQAAAAQAAIT/TAIABQOgAuoDoAAJACICEyNkAhM4 ZAAEA6AACQAAAAQAAM5ZTAQABQOgAuoDoAAJAAICISAgICA4IAAEA6AACQAAAAQAAP/gTAIA BQOgAuoDoAAJACICIXdoAiE4aAAEA6AACQAAAAQAAM5ZTAYABgOgAuoDoAAJAAICLyAgICAg ICAgTAYABgOgAuoDoAAJAAICPSAgICAgICAgTAYABgOgAuoDoAAJAAICSyAgICAgICAgTAYA BgOgAuoDoAAJAAICWSAgICAgICAgTAYABgOgAuoDoAAJAAICZyAgICAgICAgTAYABgOgAuoD oAAJAAICdSAgICAgICAgTAYABgOgAuoDoAAJAAICgyAgICAgICAgTAYABgOgAuoDoAAJAAIC kSAgICAgICAgTAYABgOgAuoDoAAJAAICnyJTdGF0ZXRhOGUABAOgAAkAAAAEAAAP4kMAAAUD oALqA6AACQAiAewABwANPQAABAOgAuoAAAAAAAIAAE4T6b4ACLpgAAAFhgAABYYAAAwHrAAA FE9QPyoIAEUABXgfEkAAQAYAAApKMRgKSgwUqB4Xgm8zfSN/czv7UBDEkAAAAAA4AQAFAyAA CQAAAAwAAM5ZAAAAAEwEAAUDIALqAyAACQACACkgICAgOCAABAMgAAkAAAAEAAD880wCAAUD IALqAyAACQAiACkiIgLqOCAABAMgAAkAAAAEAADOWUwCAAUDIALqAyAACQAyACksICAgOCAA BAMgAAkAAAAEAACE/0wPAAgDIALqAyAACQBCACkjZnJvbSB1c2VyIHBvcnQFOCAABAMgAAkA AAAEAADOWUxwACADIALqAyAACQC6ACkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgTAQABQMgAuoDIAAJAAIANyAgICA4DAAEAyAA CQAAAAQAAIT/TCsADwMgAuoDIAAJACIANyMidXNlcj1Sb2Nrc29uO3Rlc3Q9YWJjZGUiLCAj ZnJvbSB1cmkgcGFyYW0DOAEABAMgAAkAAAAEAADOWUxYABoDIALqAyAACQF6ADcgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgTAQABQMgAuoDIAAJAAIARSAgICA4AgAEAyAA CQAAAAQAAIT/TB0ADAMgAuoDIAAJACIARSMiYWJjZD04OTc2IiwgI2Zyb20gdXJpIHBhcmFt AgACOAkABAMgAAkAAAAEAADOWUxmAB4DIALqAyAACQEKAEUgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEwEAAUDIALqAyAACQACAFMgICAgOAEA BAMgAAkAAAAEAAD880wCAAUDIALqAyAACQAiAFMiIvzzOAIABAMgAAkAAAAEAADOWUwCAAUD IALqAyAACQAyAFMsIM5ZOAIABAMgAAkAAAAEAACE/0wPAAgDIALqAyAACQBCAFMjZnJvbSB1 cmkgcGFyYW0JOEIABAMgAAkAAAAEAADOWUxwACADIALqAyAACQC6AFMgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOCAABQMgAAkA AAAMAAAAAAAA+ABMAQAFAyAC6gMgAAkAIgIhcCAACUoaAAUDIALqAyAACQAjAiEBAHAAOAAA BAMgAAkAAAAEAAAP4kMiAAUDIALqAyAACQAiAhYABwANPQAABAMgAuoAAAAAAAIAADhyAAUD IAAJAAAADAAAzlkAAAAATAQABQMgAuoDIAAJAAIAUyAgICBMBAAFAyAC6gMgAAkAAgBhICAg IEwEAAUDIALqAyAACQACAG8gICAgTAQABQMgAuoDIAAJAAIAfSAgICBMBAAFAyAC6gMgAAkA AgCLICAgIEwEAAUDIALqAyAACQACAJkgICAgTAQABQMgAuoDIAAJAAIApyAgICBMBAAFAyAC 6gMgAAkAAgC1ICAgIEwEAAUDIALqAyAACQACAMMgICAgTAQABQMgAuoDIAAJAAIA0SAgICBM BAAFThPpvgAIunkAAAPGAAADxgAADAesAAAUT1A/KggARQADuB8TQABABgAACkoxGApKDBSo HheCbzOCc39zO/tQGMSQAAAAAAMgAuoDIAAJAAIA3yAgICBMBAAFAyAC6gMgAAkAAgDtICAg IEwEAAUDIALqAyAACQACAPsgICAgTAQABQMgAuoDIAAJAAIBCSAgICBMBAAFAyAC6gMgAAkA AgEXICAgIEwEAAUDIALqAyAACQACASUgICAgTAQABQMgAuoDIAAJAAIBMyAgICBMBAAFAyAC 6gMgAAkAAgFBICAgIEwEAAUDIALqAyAACQACAU8gICAgTAQABQMgAuoDIAAJAAIBXSAgICBM BAAFAyAC6gMgAAkAAgFrICAgIEwEAAUDIALqAyAACQACAXkgICAgTAQABQMgAuoDIAAJAAIB hyAgICBMBAAFAyAC6gMgAAkAAgGVICAgIEwEAAUDIALqAyAACQACAaMgICAgTAQABQMgAuoD IAAJAAIBsSAgICBMBAAFAyAC6gMgAAkAAgG/ICAgIEwEAAUDIALqAyAACQACAc0gICAgTAQA BQMgAuoDIAAJAAIB2yAgICBMBAAFAyAC6gMgAAkAAgHpICAgIEwEAAUDIALqAyAACQACAfcg ICAgTAQABQMgAuoDIAAJAAICBSAgICBMBAAFAyAC6gMgAAkAAgITICAgIEwEAAUDIALqAyAA CQACAiEgICAgTAQABQMgAuoDIAAJAAICLyk7ICBMBAAFAyAC6gMgAAkAAgI9ICAgIDhyAAQD IAAJAAAABAAAhP9MBAAFAyAC6gMgAAkAAgJLIyR1YTggAAQDIAAJAAAABAAAzllMBAAFAyAC 6gMgAAkAAgJZICAgIDggAAQDIAAJAAAABAAAR/9MBAAFAyAC6gMgAAkAAgJnJHVhLTggAAQD IAAJAAAABAAAzllMBAAFAyAC6gMgAAkAAgJ1ICAgIEwEAAUDIALqAyAACQAC AoMgICAgTAQA BQMgAuoDIAAJAAICkSAgICBMBAAFAyAC6gMgAAkAAgKfICAgIEwEAAUDIALqAyAACQACAq0g ICAgTAQABQMgAuoDIAAJAAICuyAgICBMBAAFAyAC6gMgAAkAAgLJICAgIEwEAAUDIALqAyAA CQACAtcic2JjOCAABQMgAAkAAAAMAAAAAAAA+ABMAQAFAyAC6gMgAAkAIgIhcCAgIEogAAUD IALqAyAACQAjAiEBAHAAOCAABAMgAAkAAAAEAAAP4kMgAAUDIALqAyAACQAiAhYABwANPQAA BAMgAuoAAAAAAAIAAE4T6b4ACLxFAAAAPAAAADwAFE9QPyoAE1/vmQAIAEUAACg480AAPQaz HQpKDBQKSjEYF4KLZUkSK0cm4atjUBAFwm7NAAAAAAAAAABOE+m+AAi9PQAAADwAAAA8ABRP UD8qABNf75kACABFAAAovx5AAD0GLPIKSgwUCkoxGBeCqB5/czv7bzOGA1AQBavoIwAAAAAA AAAAThPpvgAJWUMAAAA8AAAAPAAUT1A/KgATX++ZAAgARQAAKBWXQAA9BtZ5CkoMFApKMRgX gqQrBThi0nifxyRQEAW49OAAAAAAAAAAAA== --B_3392895476_2235321-- From phdgang@gmail.com Thu Jul 7 00:46:42 2011 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 AD28A21F8802; Thu, 7 Jul 2011 00:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 U2-6TDSdTa1X; Thu, 7 Jul 2011 00:46:42 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id EF59F21F88B1; Thu, 7 Jul 2011 00:46:40 -0700 (PDT) Received: by vws12 with SMTP id 12so642735vws.31 for ; Thu, 07 Jul 2011 00:46:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=j7aknFtwZbN+hhvjNF+V5Hc78GSxeMQk5FJEC3LkJ4E=; b=QC4B25zP33J63yPbS8IlNAL7LE1EJxAFG46D4e+JypY5W7wxg+I523GrUkXBrB/Zz+ 703l/sPSYWE3ekhtZ7eQZg0+F1B0JQhP4AgLR5vipo9RVu8EkH622nkJ2tUwNCoJnA0L 9qtTWHn/eK7En9IMaxsJWPl9rGf9aaLxMAzeU= MIME-Version: 1.0 Received: by 10.52.72.51 with SMTP id a19mr690915vdv.12.1310024800364; Thu, 07 Jul 2011 00:46:40 -0700 (PDT) Received: by 10.52.166.130 with HTTP; Thu, 7 Jul 2011 00:46:40 -0700 (PDT) Date: Thu, 7 Jul 2011 15:46:40 +0800 Message-ID: From: GangChen To: softwires , Behave WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [BEHAVE] [Softwire] New Version Notification for draft-murakami-softwire-4v6-translation-00.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: Thu, 07 Jul 2011 07:46:42 -0000 Dear all, We have submitted a draft regarding 4via6 stateless translation. http://tools.ietf.org/id/draft-murakami-softwire-4v6-translation-00.txt comments are welcome. A new version of I-D, draft-murakami-softwire-4v6-translation-00.txt has been successfully submitted by Tetsuya Murakami and posted to the IETF repository. Filename: draft-murakami-softwire-4v6-translation Revision: 00 Title: 4via6 Stateless Translation Creation date: 2011-07-04 WG ID: Individual Submission Number of pages: 10 Abstract: This document specify 4via6, a solution for IPv4 connectivity across IPv6 network utilizes 4rd algorithmic address mapping rule as a series of stateless IPv4 over IPv6 migration solutions. 4via6 employ stateless address translation techniques. It is useful for operators who want to provide IPv4 connectivity across restricted bandwidth IPv6 network with stateless operation. Many thanks Gang From iljitsch@muada.com Thu Jul 7 02:36:08 2011 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 8BDC921F85CA for ; Thu, 7 Jul 2011 02:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.356 X-Spam-Level: X-Spam-Status: No, score=-102.356 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, NO_RELAYS=-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 upjxJKjB1wwQ for ; Thu, 7 Jul 2011 02:36:08 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id C2A9721F85C7 for ; Thu, 7 Jul 2011 02:36:07 -0700 (PDT) Received: from [IPv6:2001:720:410:100f:223:32ff:fec4:ba94] ([IPv6:2001:720:410:100f:223:32ff:fec4:ba94]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id p679aY5F073525 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Jul 2011 11:36:35 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: Date: Thu, 7 Jul 2011 11:36:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7B7531A3-E121-4B75-A849-74CD19A1854B@muada.com> References: To: Rockson Li X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-behave-ftp64@tools.ietf.org, "behave@ietf.orgWG WG" Subject: Re: [BEHAVE] AUTH cmd and transparent mde (ftp64) 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: Thu, 07 Jul 2011 09:36:08 -0000 On 7 jul 2011, at 8:57, Rockson Li wrote: >> I could add this to the draft: >> The ALG SHOULD ignore the AUTH command and not go into transparent = mode >> if the server response is in the 4xx or 5xx ranges. >> Would that address your issue? > Yes, that would address most of issues. Ok. > Can we also cover 4yz,5yz for ADAT command here? > As said in sec 9 of RFC2228, the authentication procedure would = restart > from scratch from 4yx/5yz for either AUTH or ADAT The problem with that is that the control channel must still be = monitored by the ALG even though at this point a TLS negotiation could = be taking place. Of course it's possible to specify more knowledge of = the security mechanisms so the ALG can handle this intelligently, but = that would add complexity and dependencies on possible future security = mechanisms. I would like to avoid that, and simply draw the line at the AUTH = command: if the client issues it and the server doesn't react with an = error, the ALG steps out of the way and lets the client and server do = whatever they want to do without trying to interfere. There will be = circumstances where that doesn't produce the best possible outcome, but = at least it won't break anything that would work in the absence of the = ALG. We don't want to be all things to all people, what we need is to = increase the number of cases where FTP works without problems from about = 45 - 65 % of all cases to somewhere much closer to 100%, even if we = never quite reach 100%.= From internet-drafts@ietf.org Fri Jul 8 07:37:08 2011 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 90F4621F85D8; Fri, 8 Jul 2011 07:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 GttylKBj9AKE; Fri, 8 Jul 2011 07:37:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5B8D21F85C3; Fri, 8 Jul 2011 07:37:07 -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: 3.55 Message-ID: <20110708143707.20850.68943.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2011 07:37:07 -0700 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action: draft-ietf-behave-ftp64-12.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: Fri, 08 Jul 2011 14:37:08 -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 Av= oidance Working Group of the IETF. Title : An FTP ALG for IPv6-to-IPv4 translation Author(s) : Iljitsch van Beijnum Filename : draft-ietf-behave-ftp64-12.txt Pages : 17 Date : 2011-07-08 The File Transfer Protocol (FTP) has a very long history, and despite the fact that today other options exist to perform file transfers, FTP is still in common use. As such, it is important that in the situation where some client computers only have IPv6 connectivity while many servers are still IPv4-only and IPv6-to-IPv4 translators are used to bridge that gap, FTP is made to work through these translators to the best possible extent. FTP has an active and a passive mode, both as original commands that are IPv4-specific, and as extended, IP version agnostic commands. The only FTP mode that works without changes through an IPv6-to-IPv4 translator is extended passive. However, many existing FTP servers do not support this mode, and some clients do not ask for it. This document specifies a middlebox that may solve this mismatch. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-ftp64-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-ftp64-12.txt From iljitsch@muada.com Fri Jul 8 07:45:58 2011 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 9948721F8786; Fri, 8 Jul 2011 07:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.378 X-Spam-Level: X-Spam-Status: No, score=-102.378 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, NO_RELAYS=-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 gf6XQBQsShHX; Fri, 8 Jul 2011 07:45:58 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id D4ECA21F8874; Fri, 8 Jul 2011 07:45:57 -0700 (PDT) Received: from [IPv6:2001:720:410:100f:223:32ff:fec4:ba94] ([IPv6:2001:720:410:100f:223:32ff:fec4:ba94]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id p68EkMxj018992 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 8 Jul 2011 16:46:22 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: <20110708143707.20850.68943.idtracker@ietfa.amsl.com> Date: Fri, 8 Jul 2011 16:45:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110708143707.20850.68943.idtracker@ietfa.amsl.com> To: "behave@ietf.orgWG WG" X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-behave-ftp64@tools.ietf.org, TSV Dir , David Harrington , "behave-chairs@tools.ietf.org Chairs" , "ietf@ietf.org Discussion" Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-ftp64-12.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: Fri, 08 Jul 2011 14:45:58 -0000 On 8 jul 2011, at 16:37, internet-drafts@ietf.org wrote: > 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 : An FTP ALG for IPv6-to-IPv4 translation > Author(s) : Iljitsch van Beijnum > Filename : draft-ietf-behave-ftp64-12.txt > Pages : 17 > Date : 2011-07-08 I made a cosmetic change to the short title used in the page headers = and, after this week's discussion with Rockson Li, added this sentence: The ALG SHOULD ignore the AUTH command and not go into transparent mode if the server response is in the 4xx or 5xx ranges. See the diff between -10 and -11 for more substantitative changes as a = result of last call comments. So I believe we now have the final version of this draft. Iljitsch= From xing@cernet.edu.cn Sat Jul 9 19:16:59 2011 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 8D55221F86E3; Sat, 9 Jul 2011 19:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.903 X-Spam-Level: X-Spam-Status: No, score=-99.903 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HAS_XAIMC=2.696, 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 m8gpSdhE7L69; Sat, 9 Jul 2011 19:16:59 -0700 (PDT) Received: from cernet.edu.cn (mail.cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with SMTP id 3FA6321F85F6; Sat, 9 Jul 2011 19:16:57 -0700 (PDT) Received: from [127.0.0.1]([127.0.0.25]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm1a4e1982e5; Sun, 10 Jul 2011 10:16:56 +0800 Message-ID: <4E190B81.9080508@cernet.edu.cn> Date: Sun, 10 Jul 2011 10:16:33 +0800 From: Xing Li User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; zh-CN; rv:1.9.2.14) Gecko/20110221 Thunderbird/3.1.8 MIME-Version: 1.0 To: GangChen References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: cOo9jf0B Cc: softwires , Behave WG Subject: Re: [BEHAVE] [Softwire] New Version Notification for draft-murakami-softwire-4v6-translation-00.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: Sun, 10 Jul 2011 02:16:59 -0000 于 2011/7/7 15:46, GangChen 写é“: > Dear all, > > We have submitted a draft regarding 4via6 stateless translation. > http://tools.ietf.org/id/draft-murakami-softwire-4v6-translation-00.txt > comments are welcome. > > A new version of I-D, draft-murakami-softwire-4v6-translation-00.txt > has been successfully submitted by Tetsuya Murakami and posted to the > IETF repository. > > Filename: draft-murakami-softwire-4v6-translation > Revision: 00 > Title: 4via6 Stateless Translation > Creation date: 2011-07-04 > WG ID: Individual Submission > Number of pages: 10 The dual stateless IPv4/IPv6 translation (double translation) was proposed in 2009 in Behave WG, which is an extension of the stateless IPv4/IPv6 translation (IVI) defined in RFC6052, RFC6144, RFC6145 and RFC6219. Currently, there are two drafts. (1) dIVI (a straightforward extension of single translation): https://datatracker.ietf.org/doc/draft-xli-behave-divi/ (2) dIVI-pd (dual translation with prefix delegation): https://datatracker.ietf.org/doc/draft-xli-behave-divi-pd/ Comments are also welcome! Regards, xing > Abstract: > This document specify 4via6, a solution for IPv4 connectivity across > IPv6 network utilizes 4rd algorithmic address mapping rule as a > series of stateless IPv4 over IPv6 migration solutions. 4via6 employ > stateless address translation techniques. It is useful for operators > who want to provide IPv4 connectivity across restricted bandwidth > IPv6 network with stateless operation. > > Many thanks > > Gang > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > From internet-drafts@ietf.org Sun Jul 10 03:34:34 2011 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 0A61C21F86E0; Sun, 10 Jul 2011 03:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.101, 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 tFZ1XdKy9Y8i; Sun, 10 Jul 2011 03:34:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64CD721F86C5; Sun, 10 Jul 2011 03:34:33 -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: 3.55 Message-ID: <20110710103433.22271.73783.idtracker@ietfa.amsl.com> Date: Sun, 10 Jul 2011 03:34:33 -0700 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-02.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: Sun, 10 Jul 2011 10:34:34 -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 Av= oidance Working Group of the IETF. Title : Discovery of a Network-Specific NAT64 Prefix using a Wel= l-Known Name Author(s) : Teemu Savolainen Jouni Korhonen Filename : draft-ietf-behave-nat64-discovery-heuristic-02.txt Pages : 8 Date : 2011-07-10 This document describes a method for detecting presence of DNS64 and for learning IPv6 prefix used for protocol translation on an access network without explicit support from the access network. The method depends on existence of a known IPv4-only domain name. The information learned enables applications and hosts to perform local IPv6 address synthesis and on dual-stack accesses avoid traversal through NAT64. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-nat64-discovery-heuri= stic-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-nat64-discovery-heuris= tic-02.txt From teemu.savolainen@nokia.com Sun Jul 10 10:09:19 2011 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 69DF121F86EF for ; Sun, 10 Jul 2011 10:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 cbDOFs0zTlj1 for ; Sun, 10 Jul 2011 10:09:18 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id D0CB921F86E9 for ; Sun, 10 Jul 2011 10:09:18 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p6AH9A3a020852 for ; Sun, 10 Jul 2011 20:09:17 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 10 Jul 2011 20:04:59 +0300 Received: from 008-AM1MMR1-002.mgdnok.nokia.com (65.54.30.57) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Sun, 10 Jul 2011 19:04:58 +0200 Received: from 008-AM1MPN1-037.mgdnok.nokia.com ([169.254.7.29]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0323.002; Sun, 10 Jul 2011 19:04:58 +0200 From: To: Thread-Topic: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-02.txt Thread-Index: AQHMPvGh/ubOUh4cy0ySmy8EAgzPxpTlyNQj Date: Sun, 10 Jul 2011 17:04:57 +0000 Message-ID: <916CE6CF87173740BC8A2CE4430969620A61BB@008-AM1MPN1-037.mgdnok.nokia.com> References: <916CE6CF87173740BC8A2CE4430969620A6187@008-AM1MPN1-037.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE4430969620A6187@008-AM1MPN1-037.mgdnok.nokia.com> 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: 10 Jul 2011 17:04:59.0375 (UTC) FILETIME=[802D27F0:01CC3F23] X-Nokia-AV: Clean Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-02.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: Sun, 10 Jul 2011 17:09:19 -0000 Hi, Referring to discussions we had couple of days ago in this list; here is an= update for the non-standard NSP considerations (essentially saying they ar= e out of scope of the draft, and removing the corresponding section). Teemu ________________________________________ From: behave-bounces@ietf.org [behave-bounces@ietf.org] on behalf of ext in= ternet-drafts@ietf.org [internet-drafts@ietf.org] Sent: Sunday, July 10, 2011 1:34 PM To: i-d-announce@ietf.org Cc: behave@ietf.org Subject: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic= -02.txt 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 Av= oidance Working Group of the IETF. Title : Discovery of a Network-Specific NAT64 Prefix usin= g a Well-Known Name Author(s) : Teemu Savolainen Jouni Korhonen Filename : draft-ietf-behave-nat64-discovery-heuristic-02.tx= t Pages : 8 Date : 2011-07-10 This document describes a method for detecting presence of DNS64 and for learning IPv6 prefix used for protocol translation on an access network without explicit support from the access network. The method depends on existence of a known IPv4-only domain name. The information learned enables applications and hosts to perform local IPv6 address synthesis and on dual-stack accesses avoid traversal through NAT64. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-nat64-discovery-heuri= stic-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-nat64-discovery-heuris= tic-02.txt _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From huitema@microsoft.com Sun Jul 10 12:34:23 2011 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 A357221F8677 for ; Sun, 10 Jul 2011 12:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 wGdHZqSXFuQs for ; Sun, 10 Jul 2011 12:34:23 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id EABD121F862B for ; Sun, 10 Jul 2011 12:34:22 -0700 (PDT) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sun, 10 Jul 2011 12:34:22 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) with Microsoft SMTP Server (TLS) id 14.1.323.2; Sun, 10 Jul 2011 12:34:22 -0700 Received: from TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.52]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0289.008; Sun, 10 Jul 2011 12:34:21 -0700 From: Christian Huitema To: "teemu.savolainen@nokia.com" , "behave@ietf.org" Thread-Topic: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-02.txt Thread-Index: AQHMPvGh/ubOUh4cy0ySmy8EAgzPxpTlyNQjgAAln4A= Date: Sun, 10 Jul 2011 19:34:21 +0000 Message-ID: <22F6318E46E26B498ABC828879B08D4F1AF201@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> References: <916CE6CF87173740BC8A2CE4430969620A6187@008-AM1MPN1-037.mgdnok.nokia.com> <916CE6CF87173740BC8A2CE4430969620A61BB@008-AM1MPN1-037.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE4430969620A61BB@008-AM1MPN1-037.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.43] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-02.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: Sun, 10 Jul 2011 19:34:23 -0000 The text looks good now.=20 I still have some reservation about having all hosts use the same "well-kno= wn" name. Anything well known exposes the host to abuse by intermediaries, = e.g. gateways or firewalls who perform "special processing" of the well-kno= wn name. It would be nice to have some text somewhere saying that developer= s can program any name and address of their liking, as long as the name as = the same properties as the well-known name, e.g. only exposes IPv4 addresse= s. In fact, the draft mentions that "The host MUST NOT perform connectivity te= st for the well-known IPv4 address of the well-known name, but instead to s= ome other destination such as host vendor servers." If that is the case, wh= y not rely solely on host vendor servers, including for the discovery? I could see something like: 1) Resolve "my-vendor-ipv4-only.com"; 2) Send a request to the host, "please tell me the IPv4 address through whi= ch you received this." 3) If the reply is received, compare the IPv4 address value returned by the= host to the IPv6 address used to send the request, perform the heuristics,= discover the prefix.=20 That could actually be done using STUN. -----Original Message----- From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of= teemu.savolainen@nokia.com Sent: Sunday, July 10, 2011 10:05 AM To: behave@ietf.org Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heurist= ic-02.txt Hi, Referring to discussions we had couple of days ago in this list; here is an= update for the non-standard NSP considerations (essentially saying they ar= e out of scope of the draft, and removing the corresponding section). Teemu ________________________________________ From: behave-bounces@ietf.org [behave-bounces@ietf.org] on behalf of ext in= ternet-drafts@ietf.org [internet-drafts@ietf.org] Sent: Sunday, July 10, 2011 1:34 PM To: i-d-announce@ietf.org Cc: behave@ietf.org Subject: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic= -02.txt 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 Av= oidance Working Group of the IETF. Title : Discovery of a Network-Specific NAT64 Prefix usin= g a Well-Known Name Author(s) : Teemu Savolainen Jouni Korhonen Filename : draft-ietf-behave-nat64-discovery-heuristic-02.tx= t Pages : 8 Date : 2011-07-10 This document describes a method for detecting presence of DNS64 and for learning IPv6 prefix used for protocol translation on an access network without explicit support from the access network. The method depends on existence of a known IPv4-only domain name. The information learned enables applications and hosts to perform local IPv6 address synthesis and on dual-stack accesses avoid traversal through NAT64. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-nat64-discovery-heuri= stic-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-nat64-discovery-heuris= tic-02.txt _______________________________________________ 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 internet-drafts@ietf.org Mon Jul 11 12:08:38 2011 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 614CB1F0C4A; Mon, 11 Jul 2011 12:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 Wi1owbw+j7Vu; Mon, 11 Jul 2011 12:08:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7F4121F8C56; Mon, 11 Jul 2011 12:08:37 -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: 3.55 Message-ID: <20110711190837.10592.63452.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 12:08:37 -0700 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action: draft-ietf-behave-lsn-requirements-02.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: Mon, 11 Jul 2011 19:08:38 -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 Av= oidance Working Group of the IETF. Title : Common requirements for Carrier Grade NAT (CGN) Author(s) : Simon Perreault Ikuhei Yamagata Shin Miyakawa Akira Nakagawa Hiroyuki Ashida Filename : draft-ietf-behave-lsn-requirements-02.txt Pages : 16 Date : 2011-07-11 This document defines common requirements for Carrier-Grade NAT (CGN). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-lsn-requirements-02.t= xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-lsn-requirements-02.txt From simon.perreault@viagenie.ca Mon Jul 11 12:11:30 2011 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 8F11511E8159 for ; Mon, 11 Jul 2011 12:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 AcgJBd0fqjET for ; Mon, 11 Jul 2011 12:11:29 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id BCCB911E814C for ; Mon, 11 Jul 2011 12:11:29 -0700 (PDT) Received: from banana.viagenie.ca (unknown [IPv6:2607:fa48:c:0:58e0:435:933e:a1]) by jazz.viagenie.ca (Postfix) with ESMTPSA id D63D821F5E for ; Mon, 11 Jul 2011 15:11:28 -0400 (EDT) Message-ID: <4E1B4AE0.10006@viagenie.ca> Date: Mon, 11 Jul 2011 15:11:28 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: behave@ietf.org References: <20110711190837.10592.63452.idtracker@ietfa.amsl.com> In-Reply-To: <20110711190837.10592.63452.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-lsn-requirements-02.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: Mon, 11 Jul 2011 19:11:30 -0000 internet-drafts@ietf.org wrote, on 07/11/2011 03:08 PM: > 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 : Common requirements for Carrier Grade NAT (CGN) > Author(s) : Simon Perreault > Ikuhei Yamagata > Shin Miyakawa > Akira Nakagawa > Hiroyuki Ashida > Filename : draft-ietf-behave-lsn-requirements-02.txt > Pages : 16 > Date : 2011-07-11 This revision introduces many important changes. As far as I know it addresses every issue that was raised. Here's the change log: o CGNs MUST support at least TCP, UDP, and ICMP. o Add requirement from [I-D.ietf-intarea-ipv4-id-update]. o Add informative reference to [I-D.ietf-intarea-shared-addressing-issues]. o Add requirement (SHOULD level) for a port forwarding protocol. o Allow any pooling behavior on a per-application protocol basis. o Adjust wording for external port allocation rate limiting. o Add requirement for RFC4008 support (SHOULD level). o Adjust wording for swapping address pools when rebooting. o Add DSCP requirement (stolen from draft-jennings-behave-nat6). o Add informative reference to draft-boucadair-intarea-nat-reveal-analysis. o Add requirement for hold-down pool. o Change definition of CGN. o Avoid usage of "device" loaded word throughout the document. o Add requirement about resource exhaustion. o Change title. o Describe additional CGN topology where there is no NAT444. o Better justification for "Paired" pool behavior. o Make it clear that rate limiting allocation is for preserving CPU resources o Generalize the requirement for limiting the number of TCP sessions per mapping so that it applies to all memory-consuming state elements. o Change CPE to subscriber where it applies throughout the text. o Better terminology for bulk port allocation mechanisms. o Explain how external address pairing works with DS-Lite. 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 rpenno@juniper.net Tue Jul 12 07:45:37 2011 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 4692F21F8CD6 for ; Tue, 12 Jul 2011 07:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.542 X-Spam-Level: X-Spam-Status: No, score=-6.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 rhCVx0QJKLVg for ; Tue, 12 Jul 2011 07:45:36 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 5A20021F8C84 for ; Tue, 12 Jul 2011 07:45:35 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKThxeDon5dKrvs8L7IvczxtQj9dNtb8MW@postini.com; Tue, 12 Jul 2011 07:45:36 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 12 Jul 2011 07:43:50 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 12 Jul 2011 10:43:50 -0400 From: Reinaldo Penno To: Simon Perreault , "behave@ietf.org" Date: Tue, 12 Jul 2011 10:43:47 -0400 Thread-Topic: REQ-7 and REQ-8 Re: [BEHAVE] I-D Action: draft-ietf-behave-lsn-requirements-02.txt Thread-Index: Acw//u3oTup+MQDxRWySflA18HO00AAoy0qW Message-ID: In-Reply-To: <4E1B4AE0.10006@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.9.0.110114 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [BEHAVE] REQ-7 and REQ-8 Re: I-D Action: draft-ietf-behave-lsn-requirements-02.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, 12 Jul 2011 14:45:37 -0000 Hello Simon, Thanks for the updated draft. It shows a lot of good progress. I'm going through it and have a few questions regarding REQ-7 and REQ-8. Given there was discussion on the list about these requirements and no definite consensus on the wording or purpose ( http://www.ietf.org/mail-archive/web/behave/current/msg09433.html) I was surprised to see them in the new version. It seems we are trying to solve the address change problem in another fashion (..."This is to prevent users from receiving unwanted traffic"). As discussed in http://www.ietf.org/id/draft-ietf-pcp-base-13.txt, section 8.7, address change already happens today and traffic is directed to anothe= r CPE with or w/o CGN. " REQ-7: When a CGN loses state (due to a crash, reboot, failover to a cold standby, etc.), it MUST NOT reuse the same external IP addresses for new dynamic mappings for at least 120 seconds. Justification: This is necessary in order to prevent collisions between old and new mappings and sessions. It ensures that all established sessions are broken instead of redirected to a different peer. The previous address pool MAY of course be reused after a second loss of state." If the premise is that when a CGN reboots it looses state, can you elaborat= e on the use cases on how packets will be directed to a different peer in cas= e a CGN reboots and reuses the same NAT pool in less than 120 seconds? " REQ-8: Once an external port is deallocated, it SHOULD NOT be reallocated to a new mapping until at least 120 seconds have passed. The length of time and the maximum number of ports in this state SHOULD be configurable by the CGN administrator. Justification: This is to prevent users from receiving unwanted traffic. It also helps prevent against clock skew when mappings are logged." Another question, when you say " The length of time and the maximum number of ports in this state SHOULD be configurable by the CGN administrator." do you mean it can be configured to be less than 120 seconds Or It can configured but it needs to be more than 120 seconds. Thanks, Reinaldo On 7/11/11 12:11 PM, "Simon Perreault" wrote: > internet-drafts@ietf.org wrote, on 07/11/2011 03:08 PM: >> 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. >>=20 >> Title : Common requirements for Carrier Grade NAT (CGN) >> Author(s) : Simon Perreault >> Ikuhei Yamagata >> Shin Miyakawa >> Akira Nakagawa >> Hiroyuki Ashida >> Filename : draft-ietf-behave-lsn-requirements-02.txt >> Pages : 16 >> Date : 2011-07-11 >=20 > This revision introduces many important changes. As far as I know it addr= esses > every issue that was raised. >=20 > Here's the change log: >=20 > o CGNs MUST support at least TCP, UDP, and ICMP. >=20 > o Add requirement from [I-D.ietf-intarea-ipv4-id-update]. >=20 > o Add informative reference to > [I-D.ietf-intarea-shared-addressing-issues]. >=20 > o Add requirement (SHOULD level) for a port forwarding protocol. >=20 > o Allow any pooling behavior on a per-application protocol basis. >=20 > o Adjust wording for external port allocation rate limiting. >=20 > o Add requirement for RFC4008 support (SHOULD level). >=20 > o Adjust wording for swapping address pools when rebooting. >=20 > o Add DSCP requirement (stolen from draft-jennings-behave-nat6). >=20 > o Add informative reference to > draft-boucadair-intarea-nat-reveal-analysis. >=20 > o Add requirement for hold-down pool. >=20 > o Change definition of CGN. >=20 > o Avoid usage of "device" loaded word throughout the document. >=20 > o Add requirement about resource exhaustion. >=20 > o Change title. >=20 > o Describe additional CGN topology where there is no NAT444. >=20 > o Better justification for "Paired" pool behavior. >=20 > o Make it clear that rate limiting allocation is for preserving CPU > resources >=20 > o Generalize the requirement for limiting the number of TCP sessions > per mapping so that it applies to all memory-consuming state > elements. >=20 > o Change CPE to subscriber where it applies throughout the text. >=20 > o Better terminology for bulk port allocation mechanisms. >=20 > o Explain how external address pairing works with DS-Lite. >=20 > Simon From simon.perreault@viagenie.ca Tue Jul 12 08:19:04 2011 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 1693021F8F11 for ; Tue, 12 Jul 2011 08:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 fm8jGQU4GhAs for ; Tue, 12 Jul 2011 08:19:03 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 2CFDE21F8F0B for ; Tue, 12 Jul 2011 08:19:03 -0700 (PDT) Received: from banana.viagenie.ca (unknown [IPv6:2607:fa48:c:0:58e0:435:933e:a1]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 33B8220DC4; Tue, 12 Jul 2011 11:18:51 -0400 (EDT) Message-ID: <4E1C65DA.8050004@viagenie.ca> Date: Tue, 12 Jul 2011 11:18:50 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: Reinaldo Penno References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] REQ-7 and REQ-8 Re: I-D Action: draft-ietf-behave-lsn-requirements-02.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, 12 Jul 2011 15:19:04 -0000 Reinaldo Penno wrote, on 07/12/2011 10:43 AM: > Given there was discussion on the list about these requirements and no > definite consensus on the wording or purpose ( > http://www.ietf.org/mail-archive/web/behave/current/msg09433.html) I was > surprised to see them in the new version. My task is to edit the draft to match the WG's consensus. I'm sorry my evaluation of the consensus didn't match yours. As usual in the IETF, when you're unhappy with the contents of a draft, please discuss. ;) > It seems we are trying to solve the address change problem in another > fashion (..."This is to prevent users from receiving unwanted traffic"). > > As discussed in http://www.ietf.org/id/draft-ietf-pcp-base-13.txt, section > 8.7, address change already happens today and traffic is directed to another > CPE with or w/o CGN. If I understand correctly, address change events with DHCP are dealt with by having the DHCP server wait a while before reassigning the old address to a new subscriber. This is very similar to what is currently in our draft. So I see this as a sign we're going in the right direction. (I don't understand your objection. I'm not even sure if you're objecting.) > " REQ-7: When a CGN loses state (due to a crash, reboot, failover to a > cold standby, etc.), it MUST NOT reuse the same external IP > addresses for new dynamic mappings for at least 120 seconds. > > Justification: This is necessary in order to prevent collisions > between old and new mappings and sessions. It ensures that all > established sessions are broken instead of redirected to a > different peer. The previous address pool MAY of course be reused > after a second loss of state." > > If the premise is that when a CGN reboots it looses state, can you elaborate > on the use cases on how packets will be directed to a different peer in case > a CGN reboots and reuses the same NAT pool in less than 120 seconds? Address 1.2.3.4 is assigned to subscriber A. CGN reboots in 10 seconds. CGN assigns 1.2.3.4 to subscriber B. Subscriber B receives traffic intended for subscriber A. (Is that really what you expected me to explain?) > " REQ-8: Once an external port is deallocated, it SHOULD NOT be > reallocated to a new mapping until at least 120 seconds have > passed. The length of time and the maximum number of ports > in this state SHOULD be configurable by the CGN > administrator. > > Justification: This is to prevent users from receiving unwanted > traffic. It also helps prevent against clock skew when mappings > are logged." > > Another question, when you say " The length of time and the maximum number > of ports in this state SHOULD be configurable by the CGN administrator." do > you mean it can be configured to be less than 120 seconds > > Or > > It can configured but it needs to be more than 120 seconds. My understanding: The first SHOULD NOT still holds. So it SHOULD be fully configurable, and an administrator SHOULD NOT set it lower than 120 seconds but could do so by breaking the SHOULD NOT, which may be justified in some controlled contexts (e.g. not on the public Internet). Let me know if you can think of better wording. 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 rpenno@juniper.net Tue Jul 12 08:28:29 2011 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 06CF821F8EA4 for ; Tue, 12 Jul 2011 08:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.55 X-Spam-Level: X-Spam-Status: No, score=-6.55 tagged_above=-999 required=5 tests=[AWL=0.049, 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 b0yZa-GyLBHX for ; Tue, 12 Jul 2011 08:28:28 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id E9BF321F8EA3 for ; Tue, 12 Jul 2011 08:28:26 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKThxoGUW2VEYJ+D7Kzu6Z2Gy/DuR9NTeU@postini.com; Tue, 12 Jul 2011 08:28:28 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 12 Jul 2011 08:25:08 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 12 Jul 2011 11:25:07 -0400 From: Reinaldo Penno To: Simon Perreault Date: Tue, 12 Jul 2011 11:24:58 -0400 Thread-Topic: REQ-7 and REQ-8 Re: [BEHAVE] I-D Action: draft-ietf-behave-lsn-requirements-02.txt Thread-Index: AcxApwQYxp4yuw6NQ1yLv7F9Igq9+AAANfOo Message-ID: In-Reply-To: <4E1C65DA.8050004@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.9.0.110114 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] REQ-7 and REQ-8 Re: I-D Action: draft-ietf-behave-lsn-requirements-02.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, 12 Jul 2011 15:28:29 -0000 On 7/12/11 8:18 AM, "Simon Perreault" wrote: > Reinaldo Penno wrote, on 07/12/2011 10:43 AM: >> Given there was discussion on the list about these requirements and no >> definite consensus on the wording or purpose ( >> http://www.ietf.org/mail-archive/web/behave/current/msg09433.html) I was >> surprised to see them in the new version. >=20 > My task is to edit the draft to match the WG's consensus. I'm sorry my > evaluation of the consensus didn't match yours. As usual in the IETF, whe= n > you're unhappy with the contents of a draft, please discuss. ;) >=20 >> It seems we are trying to solve the address change problem in another >> fashion (..."This is to prevent users from receiving unwanted traffic"). >>=20 >> As discussed in http://www.ietf.org/id/draft-ietf-pcp-base-13.txt, secti= on >> 8.7, address change already happens today and traffic is directed to ano= ther >> CPE with or w/o CGN. >=20 > If I understand correctly, address change events with DHCP are dealt with= by > having the DHCP server wait a while before reassigning the old address to= a > new > subscriber. This is very similar to what is currently in our draft. So I = see > this as a sign we're going in the right direction. >=20 > (I don't understand your objection. I'm not even sure if you're objecting= .) >=20 I'm not there is such recommendation in RFC. Can we put a reference to it i= n this draft? >> " REQ-7: When a CGN loses state (due to a crash, reboot, failover to a >> cold standby, etc.), it MUST NOT reuse the same external IP >> addresses for new dynamic mappings for at least 120 seconds. >>=20 >> Justification: This is necessary in order to prevent collisions >> between old and new mappings and sessions. It ensures that all >> established sessions are broken instead of redirected to a >> different peer. The previous address pool MAY of course be reused >> after a second loss of state." >>=20 >> If the premise is that when a CGN reboots it looses state, can you elabo= rate >> on the use cases on how packets will be directed to a different peer in = case >> a CGN reboots and reuses the same NAT pool in less than 120 seconds? >=20 > Address 1.2.3.4 is assigned to subscriber A. > CGN reboots in 10 seconds. > CGN assigns 1.2.3.4 to subscriber B. > Subscriber B receives traffic intended for subscriber A. >=20 External->internal traffic would be dropped by NAT since there is no mappin= g for a specific session. What would the use case where traffic would reach subscriber B? > (Is that really what you expected me to explain?) >=20 >> " REQ-8: Once an external port is deallocated, it SHOULD NOT be >> reallocated to a new mapping until at least 120 seconds have >> passed. The length of time and the maximum number of ports >> in this state SHOULD be configurable by the CGN >> administrator. >>=20 >> Justification: This is to prevent users from receiving unwanted >> traffic. It also helps prevent against clock skew when mappings >> are logged." >>=20 >> Another question, when you say " The length of time and the maximum numb= er >> of ports in this state SHOULD be configurable by the CGN administrator."= do >> you mean it can be configured to be less than 120 seconds >>=20 >> Or >>=20 >> It can configured but it needs to be more than 120 seconds. >=20 > My understanding: The first SHOULD NOT still holds. So it SHOULD be fully > configurable, and an administrator SHOULD NOT set it lower than 120 secon= ds > but > could do so by breaking the SHOULD NOT, which may be justified in some > controlled contexts (e.g. not on the public Internet). >=20 > Let me know if you can think of better wording. I would advocate it MAY be configured to be less than 120 seconds (even in public Internet) >=20 > Simon From simon.perreault@viagenie.ca Tue Jul 12 08:47:03 2011 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 8F55421F8D2F for ; Tue, 12 Jul 2011 08:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 t9HgctQdlKPm for ; Tue, 12 Jul 2011 08:47:02 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id D075B21F8D24 for ; Tue, 12 Jul 2011 08:47:02 -0700 (PDT) Received: from banana.viagenie.ca (unknown [IPv6:2607:fa48:c:0:58e0:435:933e:a1]) by jazz.viagenie.ca (Postfix) with ESMTPSA id DB76F21F69; Tue, 12 Jul 2011 11:47:01 -0400 (EDT) Message-ID: <4E1C6C75.6050701@viagenie.ca> Date: Tue, 12 Jul 2011 11:47:01 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: Reinaldo Penno References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] REQ-7 and REQ-8 Re: I-D Action: draft-ietf-behave-lsn-requirements-02.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, 12 Jul 2011 15:47:03 -0000 Reinaldo Penno wrote, on 07/12/2011 11:24 AM: >> If I understand correctly, address change events with DHCP are dealt with by >> having the DHCP server wait a while before reassigning the old address to a >> new >> subscriber. This is very similar to what is currently in our draft. So I see >> this as a sign we're going in the right direction. >> >> (I don't understand your objection. I'm not even sure if you're objecting.) >> > > I'm not there is such recommendation in RFC. Can we put a reference to it in > this draft? I haven't found any, sorry. >> Address 1.2.3.4 is assigned to subscriber A. >> CGN reboots in 10 seconds. >> CGN assigns 1.2.3.4 to subscriber B. >> Subscriber B receives traffic intended for subscriber A. >> > > External->internal traffic would be dropped by NAT since there is no mapping > for a specific session. I don't understand. Let me add ports to make the mappings explicit: Address+port 1.2.3.4:1234 is assigned to subscriber A. CGN reboots in 10 seconds. CGN assigns 1.2.3.4:1234 to subscriber B. Subscriber B receives traffic intended for subscriber A. Note that RFC 5382 does not require NATs to track TCP session numbers (and most do not). It doesn't even require that TCP sessions be tracked at all (some NATs don't track sessions). > I would advocate it MAY be configured to be less than 120 seconds (even in > public Internet) Please explain why. Also, would you be in favour of simply dropping that requirement? 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 rpenno@juniper.net Tue Jul 12 10:21:35 2011 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 8CDB221F8B5D for ; Tue, 12 Jul 2011 10:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.256 X-Spam-Level: X-Spam-Status: No, score=-6.256 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, 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 lQShJT+aq-jO for ; Tue, 12 Jul 2011 10:21:34 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id 7109421F8B48 for ; Tue, 12 Jul 2011 10:21:33 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKThyCnFFgzwifC6gCTNL/fglbMV75p2XY@postini.com; Tue, 12 Jul 2011 10:21:34 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 12 Jul 2011 10:18:42 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 12 Jul 2011 13:18:41 -0400 From: Reinaldo Penno To: Simon Perreault Date: Tue, 12 Jul 2011 13:18:38 -0400 Thread-Topic: REQ-7 and REQ-8 Re: [BEHAVE] I-D Action: draft-ietf-behave-lsn-requirements-02.txt Thread-Index: AcxAqvOyN2hrnRwjS02LP9P76s6vywADMk8S Message-ID: In-Reply-To: <4E1C6C75.6050701@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.9.0.110114 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] REQ-7 and REQ-8 Re: I-D Action: draft-ietf-behave-lsn-requirements-02.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, 12 Jul 2011 17:21:35 -0000 On 7/12/11 8:47 AM, "Simon Perreault" wrote: > Reinaldo Penno wrote, on 07/12/2011 11:24 AM: >>> If I understand correctly, address change events with DHCP are dealt wi= th by >>> having the DHCP server wait a while before reassigning the old address = to a >>> new >>> subscriber. This is very similar to what is currently in our draft. So = I see >>> this as a sign we're going in the right direction. >>>=20 >>> (I don't understand your objection. I'm not even sure if you're objecti= ng.) >>>=20 >>=20 >> I'm not there is such recommendation in RFC. Can we put a reference to i= t in >> this draft? >=20 > I haven't found any, sorry. >=20 >>> Address 1.2.3.4 is assigned to subscriber A. >>> CGN reboots in 10 seconds. >>> CGN assigns 1.2.3.4 to subscriber B. >>> Subscriber B receives traffic intended for subscriber A. >>>=20 >>=20 >> External->internal traffic would be dropped by NAT since there is no map= ping >> for a specific session. >=20 > I don't understand. Let me add ports to make the mappings explicit: >=20 > Address+port 1.2.3.4:1234 is assigned to subscriber A. > CGN reboots in 10 seconds. > CGN assigns 1.2.3.4:1234 to subscriber B. > Subscriber B receives traffic intended for subscriber A. >=20 > Note that RFC 5382 does not require NATs to track TCP session numbers (an= d > most > do not). It doesn't even require that TCP sessions be tracked at all (som= e > NATs > don't track sessions). Stateful-NAT64 does require TCP session tracking. http://tools.ietf.org/html/rfc6146, section 3.5.2.2. State Machine for TCP Processing in the NAT64. And more related to NAPT44, if first packet of a TCP session is not-SYN I posit that most CGNs in the market will not allow the session to be established. It is just de facto behavior. Therefore I still question if there is such a use case that justifies this requirement. >=20 >> I would advocate it MAY be configured to be less than 120 seconds (even = in >> public Internet) >=20 > Please explain why. Also, would you be in favour of simply dropping that > requirement? My explanation is that we have a requirement that: 1 - Tries to address a situation where use case is not clear or does not affect most implementations. And By doing that, we get collateral damage in the form of 2 below. 2 - Create a burden for CGN deployment that certain ISPs might not care. We are making a choice of behalf of everybody else instead of giving ISP the choice. The quick numbers are crunched are in this message. http://www.ietf.org/mail-archive/web/behave/current/msg09433.html If and ISP A wants to put this requirement on their RFP, that is fine, but as standards go, we should give ISP B-Z a choice. Thanks, Reinaldo >=20 > Simon From simon.perreault@viagenie.ca Tue Jul 12 11:46:36 2011 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 4360521F8E23 for ; Tue, 12 Jul 2011 11:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, J_CHICKENPOX_75=0.6, NO_RELAYS=-0.001] 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 TvKACzWutl6u for ; Tue, 12 Jul 2011 11:46:32 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB1F21F8E11 for ; Tue, 12 Jul 2011 11:46:32 -0700 (PDT) Received: from banana.viagenie.ca (unknown [IPv6:2607:fa48:6d5c:a0:1e4b:d6ff:fe20:6cfe]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 3216E20DC6; Tue, 12 Jul 2011 14:46:31 -0400 (EDT) Message-ID: <4E1C9686.7080800@viagenie.ca> Date: Tue, 12 Jul 2011 14:46:30 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: Reinaldo Penno References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] REQ-7 and REQ-8 Re: I-D Action: draft-ietf-behave-lsn-requirements-02.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, 12 Jul 2011 18:46:36 -0000 Reinaldo Penno wrote, on 07/12/2011 01:18 PM: >> Address+port 1.2.3.4:1234 is assigned to subscriber A. >> CGN reboots in 10 seconds. >> CGN assigns 1.2.3.4:1234 to subscriber B. >> Subscriber B receives traffic intended for subscriber A. >> > And more related to NAPT44, if first packet of a TCP session is not-SYN I > posit that most CGNs in the market will not allow the session to be > established. It is just de facto behavior. Therefore I still question if > there is such a use case that justifies this requirement. But the first packet *is* a SYN! After the CGN reboots, 1.2.3.4:1234 gets assigned to B precisely because B initiated a new session with a SYN. Since the CGN is EIM, the remote peer doesn't matter. The old peer can send data through the new session if it uses the same external address+port. >>> I would advocate it MAY be configured to be less than 120 seconds (even in >>> public Internet) >> >> Please explain why. Also, would you be in favour of simply dropping that >> requirement? > > My explanation is that we have a requirement that: > > 1 - Tries to address a situation where use case is not clear or does not > affect most implementations. And By doing that, we get collateral damage in > the form of 2 below. We first need to resolve that. > 2 - Create a burden for CGN deployment that certain ISPs might not care. We > are making a choice of behalf of everybody else instead of giving ISP the > choice. The quick numbers are crunched are in this message. > > http://www.ietf.org/mail-archive/web/behave/current/msg09433.html That number crunching was addressed with the -02 revision. Instead of having two separate pools, we now only require that address+ports that were in use do not get reused within 120 seconds. This is very different. 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 rpenno@juniper.net Tue Jul 12 14:46:46 2011 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 E14B721F8B3B for ; Tue, 12 Jul 2011 14:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.628 X-Spam-Level: X-Spam-Status: No, score=-5.628 tagged_above=-999 required=5 tests=[AWL=-0.829, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, J_CHICKENPOX_74=0.6, J_CHICKENPOX_75=0.6, 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 FH26fOp5q7e1 for ; Tue, 12 Jul 2011 14:46:46 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 070C421F8B2D for ; Tue, 12 Jul 2011 14:46:44 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKThzAxI3CaPwufbNT5jOSr+YWIvldV93g@postini.com; Tue, 12 Jul 2011 14:46:46 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 12 Jul 2011 14:45:14 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 12 Jul 2011 17:45:14 -0400 From: Reinaldo Penno To: Simon Perreault Date: Tue, 12 Jul 2011 17:45:09 -0400 Thread-Topic: REQ-7 and REQ-8 Re: [BEHAVE] I-D Action: draft-ietf-behave-lsn-requirements-02.txt Thread-Index: AcxAxAYOo0oWGiGXSuWgLqOq2hEukAAGPJBe Message-ID: In-Reply-To: <4E1C9686.7080800@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.9.0.110114 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] REQ-7 and REQ-8 Re: I-D Action: draft-ietf-behave-lsn-requirements-02.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, 12 Jul 2011 21:46:47 -0000 On 7/12/11 11:46 AM, "Simon Perreault" wrote: > Reinaldo Penno wrote, on 07/12/2011 01:18 PM: >>> Address+port 1.2.3.4:1234 is assigned to subscriber A. >>> CGN reboots in 10 seconds. >>> CGN assigns 1.2.3.4:1234 to subscriber B. >>> Subscriber B receives traffic intended for subscriber A. >>>=20 >> And more related to NAPT44, if first packet of a TCP session is not-SYN = I >> posit that most CGNs in the market will not allow the session to be >> established. It is just de facto behavior. Therefore I still question if >> there is such a use case that justifies this requirement. >=20 > But the first packet *is* a SYN! After the CGN reboots, 1.2.3.4:1234 gets > assigned to B precisely because B initiated a new session with a SYN. _and_ the reply needs to be a SYN-ACK, which it will not. Otherwise it is a perfectly good session to a remote server. > Since=20 > the > CGN is EIM, the remote peer doesn't matter. The old peer can send data th= rough > the new session if it uses the same external address+port. No, it can not. Inbound sessions through EIF still need to start with a SYN= . Just because there is external public IP:port it does not mean that any connection sequence is allowed. A (private)-->SYN-->B (establishes EIF mapping) A (private)<---TCP ACK<---C (packet will be dropped) A (private)<---TCP SYN<---D (okay) Moreover, as we discussed on PCP, not all NATs are EIF capable and not all NATs enable EIF for all sessions. Therefore the requirement is overreaching its usefulness.=20 Again, I still do not see a use where this can happen. And even if there is= , based on this discussion it seems we have a misplaced requirement for a situation that is the exception. >=20 >>>> I would advocate it MAY be configured to be less than 120 seconds (eve= n in >>>> public Internet) >>>=20 >>> Please explain why. Also, would you be in favour of simply dropping tha= t >>> requirement? >>=20 >> My explanation is that we have a requirement that: >>=20 >> 1 - Tries to address a situation where use case is not clear or does not >> affect most implementations. And By doing that, we get collateral damage= in >> the form of 2 below. >=20 > We first need to resolve that. >=20 >> 2 - Create a burden for CGN deployment that certain ISPs might not care.= We >> are making a choice of behalf of everybody else instead of giving ISP th= e >> choice. The quick numbers are crunched are in this message. >>=20 >> http://www.ietf.org/mail-archive/web/behave/current/msg09433.html >=20 > That number crunching was addressed with the -02 revision. Instead of hav= ing > two > separate pools, we now only require that address+ports that were in use d= o not > get reused within 120 seconds. This is very different. Not quite. The effect is the same. In a CGN capable of, say, 250k sessions/sec, in 120 seconds, you need to have 120*250K extra ports. That i= s 468 public IP addresses. In summary, we are basically saying that even if a CGN can failover under 120 seconds, there is no point since the ISP can not reuse the ports anyway= . >=20 > Simon From simon.perreault@viagenie.ca Wed Jul 13 05:22:20 2011 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 E00C921F8AED for ; Wed, 13 Jul 2011 05:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[AWL=-0.480, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, J_CHICKENPOX_75=0.6, NO_RELAYS=-0.001] 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 mEMI5ur96pmK for ; Wed, 13 Jul 2011 05:22:16 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 307F821F8767 for ; Wed, 13 Jul 2011 05:22:16 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:21d:60ff:fed7:e732]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 6AC3120D0C; Wed, 13 Jul 2011 08:22:15 -0400 (EDT) Message-ID: <4E1D8DF6.8070900@viagenie.ca> Date: Wed, 13 Jul 2011 08:22:14 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: Reinaldo Penno References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] REQ-7 and REQ-8 Re: I-D Action: draft-ietf-behave-lsn-requirements-02.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: Wed, 13 Jul 2011 12:22:21 -0000 On 2011-07-12 17:45, Reinaldo Penno wrote: > No, it can not. Inbound sessions through EIF still need to start with a SYN. > Just because there is external public IP:port it does not mean that any > connection sequence is allowed. > > A (private)-->SYN-->B (establishes EIF mapping) > A (private)<---TCP ACK<---C (packet will be dropped) > A (private)<---TCP SYN<---D (okay) Is there any RFC that says that the packet must be dropped? As far as I know, it depends on the NAT implementation. Either dropping or forwarding is fine, AFAIK. I know that at least one CGN vendor will forward the packet (based on a written description. I haven't tested this yet.) If you're right and this is specified somewhere in an RFC, then I agree we could drop this requirement. Otherwise, we could still generalize the requirement, e.g. "a CGN MUST ensure that no traffic intended for one user gets forwarded to another user", and then list the two methods we know that work, i.e. tracking TCP sessions or waiting 120 seconds before reassigning the port. >>> 2 - Create a burden for CGN deployment that certain ISPs might not care. We >>> are making a choice of behalf of everybody else instead of giving ISP the >>> choice. The quick numbers are crunched are in this message. >>> >>> http://www.ietf.org/mail-archive/web/behave/current/msg09433.html >> >> That number crunching was addressed with the -02 revision. Instead of having >> two >> separate pools, we now only require that address+ports that were in use do not >> get reused within 120 seconds. This is very different. > > Not quite. The effect is the same. In a CGN capable of, say, 250k > sessions/sec, in 120 seconds, you need to have 120*250K extra ports. That is > 468 public IP addresses. I don't understand your math. The CGN only needs to put the port in the hold down pool when it gets reassigned to a different subscriber. The hold down pool is bypassed when the port gets reassigned to a different session but to the *same* subscriber. > In summary, we are basically saying that even if a CGN can failover under > 120 seconds, there is no point since the ISP can not reuse the ports anyway. We need to be careful here. By failover, you mean stateless failover (i.e. losing state), right? Because the case of stateful failover, this requirement does not apply. It's only when you lose state that you need to put the ports that were in use when state was lost in the hold down pool. 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 rpenno@juniper.net Wed Jul 13 06:18:54 2011 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 068D311E80D2 for ; Wed, 13 Jul 2011 06:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.845 X-Spam-Level: X-Spam-Status: No, score=-5.845 tagged_above=-999 required=5 tests=[AWL=-0.446, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, J_CHICKENPOX_75=0.6, 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 8u4Bry4gVbEy for ; Wed, 13 Jul 2011 06:18:53 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id D719911E80CE for ; Wed, 13 Jul 2011 06:18:51 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKTh2bO5odCgyNud2f6WGNKJwUSxobCiz6@postini.com; Wed, 13 Jul 2011 06:18:53 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 13 Jul 2011 06:12:03 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Wed, 13 Jul 2011 09:12:02 -0400 From: Reinaldo Penno To: Simon Perreault , "behave@ietf.org" Date: Wed, 13 Jul 2011 09:11:59 -0400 Thread-Topic: REQ-7 and REQ-8 Re: [BEHAVE] I-D Action: draft-ietf-behave-lsn-requirements-02.txt Thread-Index: AcxBV4JpP6pYSV6gT7q7tnyoJeY0jAABvAMu Message-ID: In-Reply-To: <4E1D8DF6.8070900@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.9.0.110114 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] REQ-7 and REQ-8 Re: I-D Action: draft-ietf-behave-lsn-requirements-02.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: Wed, 13 Jul 2011 13:18:54 -0000 Hi Simon, Comments inline... On 7/13/11 5:22 AM, "Simon Perreault" wrote: > On 2011-07-12 17:45, Reinaldo Penno wrote: >> No, it can not. Inbound sessions through EIF still need to start with a = SYN. >> Just because there is external public IP:port it does not mean that any >> connection sequence is allowed. >>=20 >> A (private)-->SYN-->B (establishes EIF mapping) >> A (private)<---TCP ACK<---C (packet will be dropped) >> A (private)<---TCP SYN<---D (okay) >=20 > Is there any RFC that says that the packet must be dropped? As far as I > know, it depends on the NAT implementation. Either dropping or > forwarding is fine, AFAIK. Stateful NAT64 says TCP sessions must start with SYN. Therefore I assume it applies for all sessions, otherwise something else would have been specified. >=20 > I know that at least one CGN vendor will forward the packet (based on a > written description. I haven't tested this yet.) It is possible but I believe it to be a security hole in general, not necessarily tied to reboot since an EIF mapping can be easily exploited. >=20 > If you're right and this is specified somewhere in an RFC, then I agree > we could drop this requirement. I do not believe the requirement should be dropped. I just believe it is misplaced in a sense that we are using the '120 seconds' as a jack of all trades. If the problem we are trying to solve is unwanted traffic we can be more fine grained on the solution (see below). > Otherwise, we could still generalize the > requirement, e.g. "a CGN MUST ensure that no traffic intended for one > user gets forwarded to another user", and then list the two methods we > know that work, i.e. tracking TCP sessions or waiting 120 seconds before > reassigning the port. If the problem we are trying to solve is unwanted traffic we can be more fine grained on the wording. Suggestion below. 1 - There is no issue with APF (address and port dependent filtering) whether the user tracks TCP sessions or not. Therefore the requirement should not apply to such mappings. 2 - In the case of EIF mappings, if the CGN tracks TCP sessions there is no need to wait 120 seconds. 3 - In the case of EIF mappings, if the CGN does not track TCP sessions, it SHOULD wait 120 seconds before assigning the port to a different subscribers. >=20 >>>> 2 - Create a burden for CGN deployment that certain ISPs might not car= e. We >>>> are making a choice of behalf of everybody else instead of giving ISP = the >>>> choice. The quick numbers are crunched are in this message. >>>>=20 >>>> http://www.ietf.org/mail-archive/web/behave/current/msg09433.html >>>=20 >>> That number crunching was addressed with the -02 revision. Instead of h= aving >>> two >>> separate pools, we now only require that address+ports that were in use= do >>> not >>> get reused within 120 seconds. This is very different. >>=20 >> Not quite. The effect is the same. In a CGN capable of, say, 250k >> sessions/sec, in 120 seconds, you need to have 120*250K extra ports. Tha= t is >> 468 public IP addresses. >=20 > I don't understand your math. The CGN only needs to put the port in the > hold down pool when it gets reassigned to a different subscriber. How will you know that after a reboot when all state is lost? > The > hold down pool is bypassed when the port gets reassigned to a different > session but to the *same* subscriber. >=20 >> In summary, we are basically saying that even if a CGN can failover unde= r >> 120 seconds, there is no point since the ISP can not reuse the ports any= way. >=20 > We need to be careful here. By failover, you mean stateless failover > (i.e. losing state), right? Right. The requirement seems to be hampering innovation by establishing a lower threshold for failover > Because the case of stateful failover, this > requirement does not apply. It's only when you lose state that you need > to put the ports that were in use when state was lost in the hold down po= ol. >=20 > Simon From simon.perreault@viagenie.ca Wed Jul 13 06:48:34 2011 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 7CF3421F8713 for ; Wed, 13 Jul 2011 06:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.429 X-Spam-Level: X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 pd5ayuqbWxsC for ; Wed, 13 Jul 2011 06:48:29 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 3848721F872F for ; Wed, 13 Jul 2011 06:48:29 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:21d:60ff:fed7:e732]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 809D921C25; Wed, 13 Jul 2011 09:48:28 -0400 (EDT) Message-ID: <4E1DA22C.50108@viagenie.ca> Date: Wed, 13 Jul 2011 09:48:28 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: Reinaldo Penno References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] REQ-7 and REQ-8 Re: I-D Action: draft-ietf-behave-lsn-requirements-02.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: Wed, 13 Jul 2011 13:48:34 -0000 On 2011-07-13 09:11, Reinaldo Penno wrote: >>> A (private)-->SYN-->B (establishes EIF mapping) >>> A (private)<---TCP ACK<---C (packet will be dropped) >>> A (private)<---TCP SYN<---D (okay) >> >> Is there any RFC that says that the packet must be dropped? As far as I >> know, it depends on the NAT implementation. Either dropping or >> forwarding is fine, AFAIK. > > Stateful NAT64 says TCP sessions must start with SYN. Therefore I assume it > applies for all sessions, otherwise something else would have been > specified. Well... you know where this is going... NAT64 is out of scope. This draft is only concerned with NAT44. >> I know that at least one CGN vendor will forward the packet (based on a >> written description. I haven't tested this yet.) > > It is possible but I believe it to be a security hole in general, not > necessarily tied to reboot since an EIF mapping can be easily exploited. Right. And many others go further and consider NATs that don't track TCP sequence numbers to be useless pieces of crap (which is why security-conscious OpenBSD designed pf with TCP sequence number tracking). So the security argument is relative to what one considers "secure enough". > 1 - There is no issue with APF (address and port dependent filtering) > whether the user tracks TCP sessions or not. Therefore the requirement > should not apply to such mappings. Right, but: REQ-6: It is RECOMMENDED that a CGN have an "Endpoint-Independent Filtering" behavior. > 2 - In the case of EIF mappings, if the CGN tracks TCP sessions there is no > need to wait 120 seconds. Agreed. > 3 - In the case of EIF mappings, if the CGN does not track TCP sessions, it > SHOULD wait 120 seconds before assigning the port to a different > subscribers. Agreed. >>> Not quite. The effect is the same. In a CGN capable of, say, 250k >>> sessions/sec, in 120 seconds, you need to have 120*250K extra ports. That is >>> 468 public IP addresses. >> >> I don't understand your math. The CGN only needs to put the port in the >> hold down pool when it gets reassigned to a different subscriber. > > How will you know that after a reboot when all state is lost? Ah, you're right. Thanks. I think we can reach a conclusion. If we generalize the requirement so that NATs that do TCP session tracking don't need a hold down pool, would that fully address your concern? 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 rpenno@juniper.net Wed Jul 13 07:10:57 2011 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 C79D221F87E9 for ; Wed, 13 Jul 2011 07:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.404 X-Spam-Level: X-Spam-Status: No, score=-6.404 tagged_above=-999 required=5 tests=[AWL=0.195, 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 b6D-EsuZ3fQk for ; Wed, 13 Jul 2011 07:10:57 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 16CBB21F87C9 for ; Wed, 13 Jul 2011 07:10:56 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKTh2nbxH6M0ZwdW+U+8PaihVVSj3uKvoy@postini.com; Wed, 13 Jul 2011 07:10:57 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 13 Jul 2011 07:09:52 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Wed, 13 Jul 2011 10:09:51 -0400 From: Reinaldo Penno To: Simon Perreault Date: Wed, 13 Jul 2011 10:09:49 -0400 Thread-Topic: REQ-7 and REQ-8 Re: [BEHAVE] I-D Action: draft-ietf-behave-lsn-requirements-02.txt Thread-Index: AcxBY41V9RA0pHowSMme0yOrWhSJzAAAvlo/ Message-ID: In-Reply-To: <4E1DA22C.50108@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.9.0.110114 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] REQ-7 and REQ-8 Re: I-D Action: draft-ietf-behave-lsn-requirements-02.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: Wed, 13 Jul 2011 14:10:57 -0000 On 7/13/11 6:48 AM, "Simon Perreault" wrote: > On 2011-07-13 09:11, Reinaldo Penno wrote: >>>> A (private)-->SYN-->B (establishes EIF mapping) >>>> A (private)<---TCP ACK<---C (packet will be dropped) >>>> A (private)<---TCP SYN<---D (okay) >>>=20 >>> Is there any RFC that says that the packet must be dropped? As far as I >>> know, it depends on the NAT implementation. Either dropping or >>> forwarding is fine, AFAIK. >>=20 >> Stateful NAT64 says TCP sessions must start with SYN. Therefore I assume= it >> applies for all sessions, otherwise something else would have been >> specified. >=20 > Well... you know where this is going... NAT64 is out of scope. This > draft is only concerned with NAT44. Oh well, but I hoped it would be related to CGN (address sharing) in general, otherwise we will have 3x (or more the work) when writing similar drafts for NAT64, DS-Lite, and others that fall into the 'address sharing' category. >=20 >>> I know that at least one CGN vendor will forward the packet (based on a >>> written description. I haven't tested this yet.) >>=20 >> It is possible but I believe it to be a security hole in general, not >> necessarily tied to reboot since an EIF mapping can be easily exploited. >=20 > Right. And many others go further and consider NATs that don't track TCP > sequence numbers to be useless pieces of crap (which is why > security-conscious OpenBSD designed pf with TCP sequence number > tracking). So the security argument is relative to what one considers > "secure enough". >=20 >> 1 - There is no issue with APF (address and port dependent filtering) >> whether the user tracks TCP sessions or not. Therefore the requirement >> should not apply to such mappings. >=20 > Right, but: >=20 > REQ-6: It is RECOMMENDED that a CGN have an "Endpoint-Independent > Filtering" behavior. Yes, but other types of filtering are perfectly fine depending on security and other inputs. 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. >=20 >> 2 - In the case of EIF mappings, if the CGN tracks TCP sessions there is= no >> need to wait 120 seconds. >=20 > Agreed. >=20 >> 3 - In the case of EIF mappings, if the CGN does not track TCP sessions,= it >> SHOULD wait 120 seconds before assigning the port to a different >> subscribers. >=20 > Agreed. >=20 >>>> Not quite. The effect is the same. In a CGN capable of, say, 250k >>>> sessions/sec, in 120 seconds, you need to have 120*250K extra ports. T= hat >>>> is >>>> 468 public IP addresses. >>>=20 >>> I don't understand your math. The CGN only needs to put the port in the >>> hold down pool when it gets reassigned to a different subscriber. >>=20 >> How will you know that after a reboot when all state is lost? >=20 > Ah, you're right. Thanks. >=20 > I think we can reach a conclusion. If we generalize the requirement so > that NATs that do TCP session tracking don't need a hold down pool, > would that fully address your concern? Yes, but we should also mention that the requirement does not apply to Address dependent filtering and Address and port dependent filtering. >=20 > Simon From simon.perreault@viagenie.ca Wed Jul 13 07:15:56 2011 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 9DB0E21F88D3 for ; Wed, 13 Jul 2011 07:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 Bvrlb3zCeNFx for ; Wed, 13 Jul 2011 07:15:51 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 649E021F889F for ; Wed, 13 Jul 2011 07:15:51 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:21d:60ff:fed7:e732]) by jazz.viagenie.ca (Postfix) with ESMTPSA id D19A921F6F; Wed, 13 Jul 2011 10:15:49 -0400 (EDT) Message-ID: <4E1DA895.6030708@viagenie.ca> Date: Wed, 13 Jul 2011 10:15:49 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: Reinaldo Penno References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] REQ-7 and REQ-8 Re: I-D Action: draft-ietf-behave-lsn-requirements-02.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: Wed, 13 Jul 2011 14:15:56 -0000 On 2011-07-13 10:09, Reinaldo Penno wrote: > Yes, but we should also mention that the requirement does not apply to > Address dependent filtering and Address and port dependent filtering. Will do. Thanks for the discussion! 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 jacniq@gmail.com Sun Jul 17 20:12:36 2011 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 E7E8521F84E5 for ; Sun, 17 Jul 2011 20:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.113 X-Spam-Level: X-Spam-Status: No, score=-3.113 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 zAygV2SEbEED for ; Sun, 17 Jul 2011 20:12:36 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D997D21F87AF for ; Sun, 17 Jul 2011 20:12:35 -0700 (PDT) Received: by vws12 with SMTP id 12so2673691vws.31 for ; Sun, 17 Jul 2011 20:12:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=cLyJXCKhuY+Qpu8kUdwPOlk+zyi9wzyzTH7C5+wXwL4=; b=Rkypl22nnrILWlZpvyg2Mg0+3XzAqeMytbQvDJcHEpORqurf32SCOyJ6nx9QLoDhJf yBzDCaNiZCcZcRXb/bXHi8cLIVlsnLwrwI3PiSTnVjxb6+Gi76grNslwatbtObY8nhG6 MX4WKsejZt4t5MQXdLvvBMZBS7EMWhyyEY00g= MIME-Version: 1.0 Received: by 10.52.30.197 with SMTP id u5mr5442322vdh.121.1310958754311; Sun, 17 Jul 2011 20:12:34 -0700 (PDT) Received: by 10.52.111.138 with HTTP; Sun, 17 Jul 2011 20:12:34 -0700 (PDT) Date: Mon, 18 Jul 2011 11:12:34 +0800 Message-ID: From: Jacni Qin To: behave@ietf.org, marcelo bagnulo braun , philip_matthews@magma.ca, Iljitsch van Beijnum Content-Type: multipart/alternative; boundary=bcaec51d2d7addad5904a84f5e84 Subject: [BEHAVE] Fwd: One deployment model of NAT64.//[v6ops] IPv6 content transition 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, 18 Jul 2011 03:12:37 -0000 --bcaec51d2d7addad5904a84f5e84 Content-Type: text/plain; charset=ISO-8859-1 hi all, We've posted a draft discussing one deployment model of RFC6146, to rapidly increasing the contents accessible through IPv6. http://tools.ietf.org/html/draft-sunq-v6ops-contents-transition-01 It'll be quite appreciated if you can review it and give comments. Thanks in advance. Cheers, Jacni ---------- Forwarded message ---------- From: Qiong Date: Mon, Jul 18, 2011 at 9:57 AM Subject: [v6ops] IPv6 content transition To: v6ops@ietf.org, Fred Baker Dear all, We have updated the draft for IPv6 content transition ( http://www.ietf.org/id/draft-sunq-v6ops-contents-transition-01.txt). It describes one deployment model of NAT64, aiming at rapidly increasing the amount of IPv6 accessible contents for users from IPv6 Internet. We have deployed it in Hunan province, and there are six sites (including the official website of China Telecom) have migrated through this approach. And it has also been exhibited on world IPv6 day. We sincerely have comments from you and hopeful to have a discussion on this approach in the incoming IETF 81th. Refer to the report on "The official website of China Telecom launches IPv6 address to visit formally" http://networkvip.net/archives/the-official-website-of-china-telecom-launches-ipv6-address-to-visit-formally.html Thank you very much for your interests. Best regards Qiong SUN _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --bcaec51d2d7addad5904a84f5e84 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hi all,

We've posted a draft d= iscussing one deployment model of RFC6146, to rapidly increasing the conten= ts accessible through IPv6.
http://tools.ietf.org/html/draft-sunq-v6= ops-contents-transition-01

It'll be quite appreciated if you can review it and give comments. = Thanks in advance.


Cheers,
Jacni

---------- Forwarded message ----------
From: Qiong <bingxuere@gmail.com>
Date: Mon, Jul 18, 2011 at 9:57 AM
Subject: [v6ops] IPv6 content transit= ion
To: v6ops@ietf.org, Fred Baker= <fred@cisco.com>


Dear all,

We have updated the draft for IPv6 content= transition (=A0http= ://www.ietf.org/id/draft-sunq-v6ops-contents-transition-01.txt). It des= cribes one deployment model of NAT64, aiming at rapidly increasing the amou= nt of IPv6 accessible contents for users from IPv6 Internet. We have=A0deployed it in Hunan province, and there are six sites (inclu= ding the official website of China Telecom) have=A0migrated through this ap= proach.=A0And it has also been=A0exhibited on world IPv6 = day.
<= br>
We sincerely have comments from you and hopeful = to have a discussion on this approach in the incoming IETF 81th.

Refer to the report on "Th= e official website of China Telecom launches IPv6 address to visit formally= "

Thank you very much for your interests.

Best regards

Qiong SUN


_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops


--bcaec51d2d7addad5904a84f5e84-- From dthaler@microsoft.com Thu Jul 21 18:20:13 2011 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 CAAA721F8A4D for ; Thu, 21 Jul 2011 18:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.543 X-Spam-Level: X-Spam-Status: No, score=-110.543 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 6eF3GFXSntTu for ; Thu, 21 Jul 2011 18:20:10 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 91C9421F857E for ; Thu, 21 Jul 2011 18:20:10 -0700 (PDT) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 21 Jul 2011 18:20:10 -0700 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.1.323.2; Thu, 21 Jul 2011 18:20:10 -0700 Received: from TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.59]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.01.0289.008; Thu, 21 Jul 2011 18:20:09 -0700 From: Dave Thaler To: Simon Perreault Thread-Topic: [BEHAVE] I-D Action: draft-ietf-behave-lsn-requirements-02.txt Thread-Index: AQHMP/6YQTbK8upp0kSJom5EBSBPPpTn8gcAgA+jvUA= Date: Fri, 22 Jul 2011 01:20:09 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B175DA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> References: <20110711190837.10592.63452.idtracker@ietfa.amsl.com> <4E1B4AE0.10006@viagenie.ca> In-Reply-To: <4E1B4AE0.10006@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.43] Content-Type: multipart/alternative; boundary="_000_9B57C850BB53634CACEC56EF4853FF653B175DA4TK5EX14MBXW601w_" MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-lsn-requirements-02.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: Fri, 22 Jul 2011 01:20:13 -0000 --_000_9B57C850BB53634CACEC56EF4853FF653B175DA4TK5EX14MBXW601w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I read through the latest version and I think this is very close now. Here's my feedback on -02: > REQ-7: When a CGN loses state (due to a crash, reboot, failover to a > cold standby, etc.), it MUST NOT reuse the same external IP > addresses for new dynamic mappings for at least 120 seconds. ^^^^^^^^^ I believe REQ-7 should probably say "ports" (or "address/port pairs") not "addresses". As long as there's no collisions between old and new addr/port pairs, it doesn't matter whether it uses different ports for the same address or a different address. > REQ-9: A CGN MUST handle the IPv4 ID field of translated packets as > described in [I-D.ietf-intarea-ipv4-id-update] section 9. Is this really specific to a CGN? Or would it apply to *all* NATs? The justification section implies that I-D.ietf-intarea-ipv4-id-update section 9 already provides a justification for this being CGN specific. It doesn't, as far as I can tell, so additional elaboration is needed if this (or at least raising it to a MUST) is CGN specific. > REQ-10: A CGN SHOULD support a port forwarding protocol such as the > Port Control Protocol [I-D.ietf-pcp-base]. Wording is ambiguous. What does "support" mean? For example, if it can be a PCP client but not a PCP server, does that pass? (it shouldn't) Furthermore, the justification provided is insufficient in my opinion, given that a specific protocol is not even recommended. For example, would it be ok if someone implemented the SHOULD with some protocol no CPE supported, or if every CGN vendor had a proprietary protocol? Again my point is that it's ambiguous. My personal preference would be to explicitly say that PCP server support is a SHOULD, and move pcp-base to a normative reference. > REQ-13: When a CGN is unable to create a mapping due to resource > contraints or administrative restrictions (i.e. quotas)... ^^^^^^^^^^ Typo: constraints [...] > D. and it MUST NOT delete existing mappings in order to > "make room" for the new one. I don't understand why the above is a MUST NOT (especially if the old mapping has been idle for a long time). Either provide justification or relax this. Section 4: > o destination address (but see below) > o destination port (but see below) It's unclear whether this means a CGN MUST, SHOULD, or MAY log dest addr/port. This document should be clear enough for someone to write a compliance test. In fact this entire section has no normative requirements language :( My personal opinion is that logging support is a SHOULD, but dest addr/port support is only a MAY. But I'm open to other opinions. Section 5: > There is a range of things a CGN can do: Suggest s/can/MAY/ (And as it says, it's not a complete list and I can easily imagine other algorithms that would be better in many/most cases.) -Dave > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf > Of Simon Perreault > Sent: Monday, July 11, 2011 12:11 PM > To: behave@ietf.org > Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-lsn-requirements-02.t= xt > > internet-drafts@ietf.org wrote, on 07/11= /2011 03:08 PM: > > 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 : Common requirements for Carrier Grade NAT (CGN) > > Author(s) : Simon Perreault > > Ikuhei Yamagata > > Shin Miyakawa > > Akira Nakagawa > > Hiroyuki Ashida > > Filename : draft-ietf-behave-lsn-requirements-02.txt > > Pages : 16 > > Date : 2011-07-11 > > This revision introduces many important changes. As far as I know it > addresses every issue that was raised. > > Here's the change log: > > o CGNs MUST support at least TCP, UDP, and ICMP. > > o Add requirement from [I-D.ietf-intarea-ipv4-id-update]. > > o Add informative reference to > [I-D.ietf-intarea-shared-addressing-issues]. > > o Add requirement (SHOULD level) for a port forwarding protocol. > > o Allow any pooling behavior on a per-application protocol basis. > > o Adjust wording for external port allocation rate limiting. > > o Add requirement for RFC4008 support (SHOULD level). > > o Adjust wording for swapping address pools when rebooting. > > o Add DSCP requirement (stolen from draft-jennings-behave-nat6). > > o Add informative reference to > draft-boucadair-intarea-nat-reveal-analysis. > > o Add requirement for hold-down pool. > > o Change definition of CGN. > > o Avoid usage of "device" loaded word throughout the document. > > o Add requirement about resource exhaustion. > > o Change title. > > o Describe additional CGN topology where there is no NAT444. > > o Better justification for "Paired" pool behavior. > > o Make it clear that rate limiting allocation is for preserving CPU > resources > > o Generalize the requirement for limiting the number of TCP sessions > per mapping so that it applies to all memory-consuming state > elements. > > o Change CPE to subscriber where it applies throughout the text. > > o Better terminology for bulk port allocation mechanisms. > > o Explain how external address pairing works with DS-Lite. > > 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 --_000_9B57C850BB53634CACEC56EF4853FF653B175DA4TK5EX14MBXW601w_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I read through the latest version and I think this is very close now.

 

Here's my feedback on -02:

 

> REQ-7:  When a CGN loses state (due to a crash, reboot, failov= er to a

>         cold standby, etc.)= , it MUST NOT reuse the same external IP

>         addresses for new d= ynamic mappings for at least 120 seconds.

          ^^^^^^^^^

 

I believe REQ-7 should probably say "ports" (or "address/= port pairs")

not "addresses".   As long as there's no collisions = between old and new

addr/port pairs, it doesn't matter whether it uses different ports for

the same address or a different address.

 

> REQ-9:  A CGN MUST handle the IPv4 ID field of translated pack= ets as

>         described in [I-D.i= etf-intarea-ipv4-id-update] section 9.

 

Is this really specific to a CGN?  Or would it apply to *all= * NATs?

The justification section implies that I-D.ietf-intarea-ipv4-id-update

section 9 already provides a justification for this being CGN specific.<= o:p>

It doesn't, as far as I can tell, so additional elaboration is needed

if this (or at least raising it to a MUST) is CGN specific.

 

> REQ-10:  A CGN SHOULD support a port forwarding protocol such = as the

>          Port Control = Protocol [I-D.ietf-pcp-base].

 

Wording is ambiguous.  What does "support" mean?  Fo= r example, if it

can be a PCP client but not a PCP server, does that pass? (it shouldn= 217;t)

Furthermore, the justification provided is insufficient in my opinion,

given that a specific protocol is not even recommended.  For exampl= e,

would it be ok if someone implemented the SHOULD with some protocol=

no CPE supported, or if every CGN vendor had a proprietary protocol?

Again my point is that it's ambiguous.  My personal preference woul= d be

to explicitly say that PCP server support is a SHOULD, and move pcp-base=

to a normative reference.

 

>   REQ-13:  When a CGN is unable to create a mapping = due to resource

>            c= ontraints or administrative restrictions (i.e. quotas)...=

            = ^^^^^^^^^^

Typo: constraints

 

[…]

>            D= .  and it MUST NOT delete existing mappings in order to

>           &n= bsp;    "make room" for the new one.

 

I don't understand why the above is a MUST NOT (especially if the old

mapping has been idle for a long time).  Either provide justificati= on

or relax this.

 

Section 4:

>   o  destination address (but see below)<= /span>

>   o  destination port (but see below)

 

It's unclear whether this means a CGN MUST, SHOULD,

or MAY log dest addr/port.   This document should be

clear enough for someone to write a compliance test.

In fact this entire section has no normative

requirements language :(

 

My personal opinion is that logging support is a

SHOULD, but dest addr/port support is only a MAY.

But I'm open to other opinions.

 

Section 5:

> There is a range of things a CGN can do:

 

Suggest s/can/MAY/

 

(And as it says, it's not a complete list and

I can easily imagine other algorithms that would

be better in many/most cases.)

 

-Dave

 

> -----Original Message-----

> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On B= ehalf

> Of Simon Perreault

> Sent: Monday, July 11, 2011 12:11 PM

> To: behave@ietf.org

> Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-lsn-requirement= s-02.txt

>

> internet-drafts@ietf.= org wrote, on 07/11/2011 03:08 PM:

> > A New Internet-Draft is available from the on-line Internet-Dr= afts

> directories. This draft is a work item of the Behavior Engineering = for

> Hindrance Avoidance Working Group of the IETF.

> >

> > Title         &nb= sp; : Common requirements for Carrier Grade NAT (CGN)

> > Author(s)       : Simon Perreaul= t

> >          &nb= sp;            =     Ikuhei Yamagata

> >          &nb= sp;             = ;   Shin Miyakawa

> >          &nb= sp;            =     Akira Nakagawa

> >          &nb= sp;            =     Hiroyuki Ashida

> > Filename        : draft-iet= f-behave-lsn-requirements-02.txt

> > Pages         &nb= sp; : 16

> > Date         &nbs= p;  : 2011-07-11

>

> This revision introduces many important changes. As far as I know i= t

> addresses every issue that was raised.

>

> Here's the change log:

>

>    o  CGNs MUST support at least TCP, UDP, and = ICMP.

>

>    o  Add requirement from [I-D.ietf-intarea-ip= v4-id-update].

>

>    o  Add informative reference to

>       [I-D.ietf-intarea-shared-addres= sing-issues].

>

>    o  Add requirement (SHOULD level) for a port= forwarding protocol.

>

>    o  Allow any pooling behavior on a per-appli= cation protocol basis.

>

>    o  Adjust wording for external port allocati= on rate limiting.

>

>    o  Add requirement for RFC4008 support (SHOU= LD level).

>

>    o  Adjust wording for swapping address pools= when rebooting.

>

>    o  Add DSCP requirement (stolen from draft-j= ennings-behave-nat6).

>

>    o  Add informative reference to

>       draft-boucadair-intarea-nat-rev= eal-analysis.

>

>    o  Add requirement for hold-down pool.<= /o:p>

>

>    o  Change definition of CGN.

>

>    o  Avoid usage of "device" loaded = word throughout the document.

>

>    o  Add requirement about resource exhaustion= .

>

>    o  Change title.

>

>    o  Describe additional CGN topology where th= ere is no NAT444.

>

>    o  Better justification for "Paired&quo= t; pool behavior.

>

>    o  Make it clear that rate limiting allocati= on is for preserving CPU

>       resources

>

>    o  Generalize the requirement for limiting t= he number of TCP sessions

>       per mapping so that it applies = to all memory-consuming state

>       elements.

>

>    o  Change CPE to subscriber where it applies= throughout the text.

>

>    o  Better terminology for bulk port allocati= on mechanisms.

>

>    o  Explain how external address pairing work= s with DS-Lite.

>

> Simon

> --

> DTN made easy, lean, and smart --> http://postellation.viagenie.ca

> NAT64/DNS64 open-source        -= -> http://ecdysis.viagenie.ca

> STUN/TURN server        &nb= sp;      --> http://numb.viagenie.ca

> _______________________________________________

> Behave mailing list

> Behave@ietf.org

> https://www.ietf.org/= mailman/listinfo/behave

 

--_000_9B57C850BB53634CACEC56EF4853FF653B175DA4TK5EX14MBXW601w_-- From simon.perreault@viagenie.ca Fri Jul 22 07:13:24 2011 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 C8F6C21F8A64 for ; Fri, 22 Jul 2011 07:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 NwNztoB+Ggaf for ; Fri, 22 Jul 2011 07:13:24 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id C8D0E21F8A4F for ; Fri, 22 Jul 2011 07:13:23 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:21d:60ff:fed7:e732]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 027C720D23; Fri, 22 Jul 2011 10:13:22 -0400 (EDT) Message-ID: <4E298582.70607@viagenie.ca> Date: Fri, 22 Jul 2011 10:13:22 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: Dave Thaler References: <20110711190837.10592.63452.idtracker@ietfa.amsl.com> <4E1B4AE0.10006@viagenie.ca> <9B57C850BB53634CACEC56EF4853FF653B175DA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B175DA4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-lsn-requirements-02.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: Fri, 22 Jul 2011 14:13:24 -0000 On 2011-07-21 21:20, Dave Thaler wrote: >> REQ-7: When a CGN loses state (due to a crash, reboot, failover to a >> cold standby, etc.), it MUST NOT reuse the same external IP >> addresses for new dynamic mappings for at least 120 seconds. > ^^^^^^^^^ > > I believe REQ-7 should probably say "ports" (or "address/port pairs") > not "addresses". As long as there's no collisions between old and new > addr/port pairs, it doesn't matter whether it uses different ports for > the same address or a different address. Agreed. >> REQ-9: A CGN MUST handle the IPv4 ID field of translated packets as >> described in [I-D.ietf-intarea-ipv4-id-update] section 9. > > Is this really specific to a CGN? Or would it apply to **all** NATs? > The justification section implies that I-D.ietf-intarea-ipv4-id-update > section 9 already provides a justification for this being CGN specific. > It doesn't, as far as I can tell, so additional elaboration is needed > if this (or at least raising it to a MUST) is CGN specific. Thanks for pointing this out. As editor I was torn between recording WG consensus and my own opinion. In my opinion this requirement should be deleted. I-D.ietf-intarea-ipv4-id-update as it stands already contains normative text that applies to all NATs, so it definitely already includes CGNs. So I don't think we need to say anything additional in this document. >> REQ-10: A CGN SHOULD support a port forwarding protocol such as the >> Port Control Protocol [I-D.ietf-pcp-base]. > > Wording is ambiguous. What does "support" mean? For example, if it > can be a PCP client but not a PCP server, does that pass? (it shouldn’t) Agreed. > Furthermore, the justification provided is insufficient in my opinion, > given that a specific protocol is not even recommended. For example, > would it be ok if someone implemented the SHOULD with some protocol > no CPE supported, or if every CGN vendor had a proprietary protocol? > Again my point is that it's ambiguous. My personal preference would be > to explicitly say that PCP server support is a SHOULD, and move pcp-base > to a normative reference. I share your preference. In other words: +1 >> REQ-13: When a CGN is unable to create a mapping due to resource >> contraints or administrative restrictions (i.e. quotas)... > ^^^^^^^^^^ > > Typo: constraints > > […] > >> D. and it MUST NOT delete existing mappings in order to >> "make room" for the new one. > > I don't understand why the above is a MUST NOT (especially if the old > mapping has been idle for a long time). Either provide justification > or relax this. In my understanding, the justification is because applications generally handle connection establishment failure better than established connection failure. I'm fine with relaxing this to a SHOULD NOT. > Section 4: > >> o destination address (but see below) >> o destination port (but see below) > > It's unclear whether this means a CGN MUST, SHOULD, > or MAY log dest addr/port. This document should be > clear enough for someone to write a compliance test. > In fact this entire section has no normative > requirements language :( My understanding is that the whole section is non-normative. > My personal opinion is that logging support is a > SHOULD, but dest addr/port support is only a MAY. > But I'm open to other opinions. I'll let the WG discuss that. > Section 5: > >> There is a range of things a CGN can do: > > Suggest s/can/MAY/ > > (And as it says, it's not a complete list and > I can easily imagine other algorithms that would > be better in many/most cases.) Right. Once again I understand this section to be non-normative. I'm fine with transforming it into normative requirements, but there needs to be WG discussion about what a CGN MAY/SHOULD/MUST do. 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 dwing@cisco.com Fri Jul 22 14:09:59 2011 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 46F5521F8B30 for ; Fri, 22 Jul 2011 14:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.217 X-Spam-Level: X-Spam-Status: No, score=-105.217 tagged_above=-999 required=5 tests=[AWL=-2.618, 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 JZwOA0rp+4fI for ; Fri, 22 Jul 2011 14:09:58 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9987421F8B26 for ; Fri, 22 Jul 2011 14:09:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=885; q=dns/txt; s=iport; t=1311368998; x=1312578598; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=HkNkGnj1J6dkVQ4a9kjs4cYkPmTeCeMGOKUVRBCoouM=; b=mt258EEecnSjJDKkPlm+dHf+/63cXKDp50eN2MhIVD3xnLFZllN+t22x 6SHKmBaF3euZgaXkvLeHXDkP0fvCQ5al0OKTte1/3inQk1UJwjrX81sl2 YwwSS3ohNsc8kA5VSRmeV08swySq5YSVZbCeeWLcZFcPnMuG2rZIwR+pC 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmoGAJXmKU6rRDoI/2dsb2JhbABTmECBJ41ld6ZIniGGPwSHVZwY X-IronPort-AV: E=Sophos;i="4.67,249,1309737600"; d="scan'208";a="5627409" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-1.cisco.com with ESMTP; 22 Jul 2011 21:09:37 +0000 Received: from dwingWS ([10.32.240.196]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6ML9aGd003672; Fri, 22 Jul 2011 21:09:37 GMT From: "Dan Wing" To: Date: Fri, 22 Jul 2011 14:09:36 -0700 Message-ID: <000101cc48b3$a9f87500$fde95f00$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxImw6xYcizfz1QRMOj/AxfKwvyXA== Content-Language: en-us Cc: draft-ietf-behave-nat64-learn-analysis@tools.ietf.org Subject: [BEHAVE] WGLC: draft-ietf-behave-nat64-learn-analysis-00 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, 22 Jul 2011 21:09:59 -0000 This starts a 3 week WGLC (extra time to accommodate IETF travel) for draft-ietf-behave-nat64-learn-analysis-00. This document analyzes the available approaches for a host to learn its NAT64 prefix. Abstract: Hosts and applications may benefit from the knowledge if an IPv6 address is synthesized, which would mean a NAT64 is used to reach the IPv4 network or Internet. This document analyses a number of proposed solutions for communicating whether the synthesis is taking place, used address format, and the IPv6 prefix used by the NAT64 and DNS64. The solutions enable both NAT64 avoidance and intentional utilization by allowing local IPv6 address synthesis. The document concludes by recommending selection of heuristic discovery based solution. Please send comments to behave@ietf.org. WGLC ends in 3 weeks on August 12. -d From internet-drafts@ietf.org Mon Jul 25 09:19:40 2011 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 D6D4E21F874F; Mon, 25 Jul 2011 09:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 ZZmlljy-kZFX; Mon, 25 Jul 2011 09:19:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F5AA21F8B9A; Mon, 25 Jul 2011 09:18:13 -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: 3.56 Message-ID: <20110725161813.18404.85255.idtracker@ietfa.amsl.com> Date: Mon, 25 Jul 2011 09:18:13 -0700 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action: draft-ietf-behave-v4v6-bih-05.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: Mon, 25 Jul 2011 16:19:41 -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 Av= oidance Working Group of the IETF. Title : Dual Stack Hosts Using "Bump-in-the-Host" (BIH) Author(s) : Bill Huang Hui Deng Teemu Savolainen Filename : draft-ietf-behave-v4v6-bih-05.txt Pages : 28 Date : 2011-07-25 Bump-In-the-Host (BIH) is a host-based IPv4 to IPv6 protocol translation mechanism that allows a class of IPv4-only applications that work through NATs to communicate with IPv6-only peers. The host on which applications are running may be connected to IPv6-only or dual-stack access networks. BIH hides IPv6 and makes the IPv4-only applications think they are talking with IPv4 peers by local synthesis of IPv4 addresses. This draft obsoletes RFC 2767 and RFC 3338. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-v4v6-bih-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-v4v6-bih-05.txt From rpenno@juniper.net Mon Jul 25 09:47:26 2011 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 0DFB521F8BBC for ; Mon, 25 Jul 2011 09:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.438 X-Spam-Level: X-Spam-Status: No, score=-6.438 tagged_above=-999 required=5 tests=[AWL=0.161, 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 I18gMYaSq8nd for ; Mon, 25 Jul 2011 09:47:25 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 304D021F8BBA for ; Mon, 25 Jul 2011 09:47:22 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKTi2eGaBA6DxAEcVAFx84muAGAe4Zs81c@postini.com; Mon, 25 Jul 2011 09:47:25 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 25 Jul 2011 09:43:49 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Mon, 25 Jul 2011 12:43:48 -0400 From: Reinaldo Penno To: "behave@ietf.org" Date: Mon, 25 Jul 2011 12:43:46 -0400 Thread-Topic: New Version Notification for draft-penno-behave-rfc4787-5382-5508-bis-00.txt Thread-Index: AcxK6a5NHVHeJH6LTMC9+beitK0R/AAAFcUs Message-ID: In-Reply-To: <20110725164115.11165.59975.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.9.0.110114 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [BEHAVE] New Version Notification for draft-penno-behave-rfc4787-5382-5508-bis-00.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: Mon, 25 Jul 2011 16:47:26 -0000 http://www.ietf.org/id/draft-penno-behave-rfc4787-5382-5508-bis-00.txt ------ Forwarded Message From: "internet-drafts@ietf.org" Date: Mon, 25 Jul 2011 12:41:15 -0400 To: Reinaldo Penno Cc: "simon.perreault@viagenie.ca" , Sarat Kamisetty , Reinaldo Penno Subject: New Version Notification for draft-penno-behave-rfc4787-5382-5508-bis-00.txt A new version of I-D, draft-penno-behave-rfc4787-5382-5508-bis-00.txt has been successfully submitted by Renaldo Penno and posted to the IETF repository. Filename: draft-penno-behave-rfc4787-5382-5508-bis Revision: 00 Title: Network Address Translation (NAT) Behavioral Requirements Updates Creation date: 2011-07-25 WG ID: Individual Submission Number of pages: 9 Abstract: This document clarifies and updates several requirements of RFC4787, RFC5382 and RFC5508 based on operational and development experience. The focus of this document is NAPT44. =20 The IETF Secretariat ------ End of Forwarded Message From teemu.savolainen@nokia.com Tue Jul 26 06:43:56 2011 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 F40DA21F8C6A for ; Tue, 26 Jul 2011 06:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.873 X-Spam-Level: X-Spam-Status: No, score=-2.873 tagged_above=-999 required=5 tests=[AWL=0.726, BAYES_00=-2.599, 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 pAjU5pRmG4Iv for ; Tue, 26 Jul 2011 06:43:55 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 6898A21F8B72 for ; Tue, 26 Jul 2011 06:43:53 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p6QDhVKh019360; Tue, 26 Jul 2011 16:43:52 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Jul 2011 16:43:44 +0300 Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 26 Jul 2011 15:43:43 +0200 Received: from 008-AM1MPN1-037.mgdnok.nokia.com ([169.254.7.163]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0323.002; Tue, 26 Jul 2011 15:43:43 +0200 From: To: , Thread-Topic: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-02.txt Thread-Index: AQHMPvGh/ubOUh4cy0ySmy8EAgzPxpTlyNQjgAAln4CAGMXh8A== Date: Tue, 26 Jul 2011 13:43:42 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962A69390@008-AM1MPN1-037.mgdnok.nokia.com> References: <916CE6CF87173740BC8A2CE4430969620A6187@008-AM1MPN1-037.mgdnok.nokia.com> <916CE6CF87173740BC8A2CE4430969620A61BB@008-AM1MPN1-037.mgdnok.nokia.com> <22F6318E46E26B498ABC828879B08D4F1AF201@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <22F6318E46E26B498ABC828879B08D4F1AF201@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Company Confidential;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IiK+ntKbo4xPTApCTPxRn9XGhbBnmCVqn5Q5Oymo/pQG4Q2g2yALHK/AW/m+afozOvOn+8bMVc7Zy6+hIsveiaI9RdEGc6jarhyEIAe53QhoUoTDwyK+gDR+1Z8eyQ/GDy5LgM4dqFeIXJZ/cDaNfgv4r1acucRNO3rG2E9g/rrcwZ6aCeprE5LGrDBr9tob0qdH9gZ9n4CCajG2ZVRs+aBNIXGp1nsgn7oOI+xAb37zikilXDSV+YYRpvRFrt9fP1GL4CMdUWdVvum7D6PpYr4= x-originating-ip: [10.162.78.119] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 26 Jul 2011 13:43:44.0030 (UTC) FILETIME=[0951BBE0:01CC4B9A] X-Nokia-AV: Clean Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-02.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, 26 Jul 2011 13:43:56 -0000 Hi, Well.. it seems well-known/vendor specific names is tradeoff to decide on. = Maybe there will be further opinions/discussion on behave WG session? The connectivity test is not mandatory, it depends. For example a web brows= er seeing IPv4 literal may not need to do any connectivity test, but just t= ry to connect via locally synthesized IPv6 address and succeed or fail. I w= rote the connectivity test to well-known name should not be made as it migh= t invite too much traffic to party hosting the name. I agree STUN could be used/enhanced for the detection, but it requires use = of STUN and especially in simpler cases that probably is not available. Best regards, Teemu > -----Original Message----- > From: ext Christian Huitema [mailto:huitema@microsoft.com] > Sent: 10. hein=E4kuuta 2011 22:34 > To: Savolainen Teemu (Nokia-CTO/Tampere); behave@ietf.org > Subject: RE: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuri= stic- > 02.txt >=20 > The text looks good now. >=20 > I still have some reservation about having all hosts use the same "well-k= nown" > name. Anything well known exposes the host to abuse by intermediaries, e.= g. > gateways or firewalls who perform "special processing" of the well-known > name. It would be nice to have some text somewhere saying that developers > can program any name and address of their liking, as long as the name as = the > same properties as the well-known name, e.g. only exposes IPv4 addresses. >=20 > In fact, the draft mentions that "The host MUST NOT perform connectivity = test > for the well-known IPv4 address of the well-known name, but instead to so= me > other destination such as host vendor servers." If that is the case, why = not rely > solely on host vendor servers, including for the discovery? >=20 > I could see something like: >=20 > 1) Resolve "my-vendor-ipv4-only.com"; > 2) Send a request to the host, "please tell me the IPv4 address through w= hich > you received this." > 3) If the reply is received, compare the IPv4 address value returned by t= he host > to the IPv6 address used to send the request, perform the heuristics, dis= cover > the prefix. >=20 > That could actually be done using STUN. >=20 >=20 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf > Of teemu.savolainen@nokia.com > Sent: Sunday, July 10, 2011 10:05 AM > To: behave@ietf.org > Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuri= stic- > 02.txt >=20 > Hi, >=20 > Referring to discussions we had couple of days ago in this list; here is = an update > for the non-standard NSP considerations (essentially saying they are out = of > scope of the draft, and removing the corresponding section). >=20 > Teemu > ________________________________________ > From: behave-bounces@ietf.org [behave-bounces@ietf.org] on behalf of ext > internet-drafts@ietf.org [internet-drafts@ietf.org] > Sent: Sunday, July 10, 2011 1:34 PM > To: i-d-announce@ietf.org > Cc: behave@ietf.org > Subject: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heurist= ic- > 02.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Behavior Engineering for Hindrance Avoid= ance > Working Group of the IETF. >=20 > Title : Discovery of a Network-Specific NAT64 Prefix us= ing a Well- > Known Name > Author(s) : Teemu Savolainen > Jouni Korhonen > Filename : draft-ietf-behave-nat64-discovery-heuristic-02.= txt > Pages : 8 > Date : 2011-07-10 >=20 > This document describes a method for detecting presence of DNS64 and > for learning IPv6 prefix used for protocol translation on an access > network without explicit support from the access network. The method > depends on existence of a known IPv4-only domain name. The > information learned enables applications and hosts to perform local > IPv6 address synthesis and on dual-stack accesses avoid traversal > through NAT64. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-behave-nat64-discovery-heu= ristic- > 02.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-nat64-discovery-heur= istic- > 02.txt > _______________________________________________ > 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 yding@cs.helsinki.fi Tue Jul 26 08:47:09 2011 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 5DFF811E810B for ; Tue, 26 Jul 2011 08:47:09 -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 b2PA9D21zvcd for ; Tue, 26 Jul 2011 08:47:08 -0700 (PDT) Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3FB11E80D8 for ; Tue, 26 Jul 2011 08:47:08 -0700 (PDT) Received: from [128.214.9.154] (wel-33.cs.helsinki.fi [128.214.9.154]) (AUTH: PLAIN yding, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Tue, 26 Jul 2011 18:47:06 +0300 id 0008C137.4E2EE17A.0000770A Message-ID: <4E2EE17A.3060908@cs.helsinki.fi> Date: Tue, 26 Jul 2011 18:47:06 +0300 From: "Yi Ding(Aaron)" User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: teemu.savolainen@nokia.com, huitema@microsoft.com References: <916CE6CF87173740BC8A2CE4430969620A6187@008-AM1MPN1-037.mgdnok.nokia.com> <916CE6CF87173740BC8A2CE4430969620A61BB@008-AM1MPN1-037.mgdnok.nokia.com> <22F6318E46E26B498ABC828879B08D4F1AF201@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <916CE6CF87173740BC8A2CE443096962A69390@008-AM1MPN1-037.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE443096962A69390@008-AM1MPN1-037.mgdnok.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: behave@ietf.org Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-02.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, 26 Jul 2011 15:47:09 -0000 Hi, Concerning the vendor specific names, there is a statement in Section 8.1 "A global address is required as otherwise DNS64 entity will not perform AAAA record synthesis. The address does not have to be routable as no communications are initiated to the IPv4 address." This somehow restricts the developers to play with any name or address of their liking, especially on host vendor servers with local visibility to DNS64. According to previous tests with ecdysis-DNS64, if such IPv4 address and v4-only names exist in local DB instead of global, DNS64 simply bypasses the AAAA synthesis. Not sure whether such behaviors appear on other implementations or not. but this certainly posts a limitation. The well-known names approach is better in this aspect although it does not solve all the issues. -- Aaron On 26/07/11 16:43, teemu.savolainen@nokia.com wrote: > Hi, > > Well.. it seems well-known/vendor specific names is tradeoff to decide on. Maybe there will be further opinions/discussion on behave WG session? > > The connectivity test is not mandatory, it depends. For example a web browser seeing IPv4 literal may not need to do any connectivity test, but just try to connect via locally synthesized IPv6 address and succeed or fail. I wrote the connectivity test to well-known name should not be made as it might invite too much traffic to party hosting the name. > > I agree STUN could be used/enhanced for the detection, but it requires use of STUN and especially in simpler cases that probably is not available. > > Best regards, > > Teemu > >> -----Original Message----- >> From: ext Christian Huitema [mailto:huitema@microsoft.com] >> Sent: 10. heinäkuuta 2011 22:34 >> To: Savolainen Teemu (Nokia-CTO/Tampere); behave@ietf.org >> Subject: RE: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic- >> 02.txt >> >> The text looks good now. >> >> I still have some reservation about having all hosts use the same "well-known" >> name. Anything well known exposes the host to abuse by intermediaries, e.g. >> gateways or firewalls who perform "special processing" of the well-known >> name. It would be nice to have some text somewhere saying that developers >> can program any name and address of their liking, as long as the name as the >> same properties as the well-known name, e.g. only exposes IPv4 addresses. >> >> In fact, the draft mentions that "The host MUST NOT perform connectivity test >> for the well-known IPv4 address of the well-known name, but instead to some >> other destination such as host vendor servers." If that is the case, why not rely >> solely on host vendor servers, including for the discovery? >> >> I could see something like: >> >> 1) Resolve "my-vendor-ipv4-only.com"; >> 2) Send a request to the host, "please tell me the IPv4 address through which >> you received this." >> 3) If the reply is received, compare the IPv4 address value returned by the host >> to the IPv6 address used to send the request, perform the heuristics, discover >> the prefix. >> >> That could actually be done using STUN. >> >> >> -----Original Message----- >> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf >> Of teemu.savolainen@nokia.com >> Sent: Sunday, July 10, 2011 10:05 AM >> To: behave@ietf.org >> Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic- >> 02.txt >> >> Hi, >> >> Referring to discussions we had couple of days ago in this list; here is an update >> for the non-standard NSP considerations (essentially saying they are out of >> scope of the draft, and removing the corresponding section). >> >> Teemu From behcetsarikaya@yahoo.com Wed Jul 27 12:38:09 2011 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 4C83F5E8034 for ; Wed, 27 Jul 2011 12:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.53 X-Spam-Level: X-Spam-Status: No, score=-1.53 tagged_above=-999 required=5 tests=[AWL=-0.419, BAYES_05=-1.11] 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 9kPNxWGerljG for ; Wed, 27 Jul 2011 12:38:08 -0700 (PDT) Received: from nm29-vm0.bullet.mail.sp2.yahoo.com (nm29-vm0.bullet.mail.sp2.yahoo.com [98.139.91.236]) by ietfa.amsl.com (Postfix) with SMTP id 610BA5E800B for ; Wed, 27 Jul 2011 12:38:08 -0700 (PDT) Received: from [98.139.91.67] by nm29.bullet.mail.sp2.yahoo.com with NNFMP; 27 Jul 2011 19:38:04 -0000 Received: from [98.139.91.8] by tm7.bullet.mail.sp2.yahoo.com with NNFMP; 27 Jul 2011 19:38:04 -0000 Received: from [127.0.0.1] by omp1008.mail.sp2.yahoo.com with NNFMP; 27 Jul 2011 19:38:04 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 822619.71184.bm@omp1008.mail.sp2.yahoo.com Received: (qmail 33355 invoked by uid 60001); 27 Jul 2011 19:38:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1311795483; bh=Zcn3zh4Mep7UVANh6U+ERV16uR7i+Z6bu4iGGeCFzr4=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=lo83lM/wn+2ADuPuFKVbrrc+Hv3mWOqc9rwU09a+F9htdG2BBfxJ+R4YLp4KSd5KYS0TgGS4VEyAf6tk/IODZM/TWaemk0LGyF1VxreB3+CJU+g4beocEidnFt3n9gPMb/9yDfynNycsfut0lwI04l1cP5MmSKwg9zSZV195f0I= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=aM0oHSAMwSP1MduAY/dE1HNJaapuKB/4O2YwAXdtM4oUAM4PQtXK5QhbBZar0c2w2+hOKecghuYZfxCdEiyOQABh73QVbEcOskLNdt56bVLSdt1H/kvt2g/7KtCikG/QkDPxIMpjEmneqf9FQlNhNRBhYH75ndOoNwl4PGjm+xw=; X-YMail-OSG: vTs9HX4VM1ltDWnLZXYhFL4AlUdbrCnM6BmA4V5Uk2WIyxe gn.LKm0B4XP8wNSPvXDcmH9mCo_w6ncb6ntk9p.hRXbBpN7WeLHA5fB4E6LW vYFondmrBCBR3Ia9zT3MSnfodFVu.QEuOEWqRz6VRdmvhbfyQRWba.xHwYBI ldZroDfoq72KPh3H3zUHmVsXhUXGqtHWt537lfZZNX1oyVx4JB2IdTw37YDx 1qCDFFv3KurIH10QzsTE9YdnBcybY0tEHypptz49A3azMT2KE15ZV37OccXL u85GKBV.dqxgtHCaLJUCADb68s68CphYQ0wOvd7Seqc5Zgmbol_uUFjUqcMQ K7H.mhNxn0bKt8gelC4ghMZwqP3a7jih8Jk4r_6DriD_WfmLYX9j28ugk9_q X8q7yd3zlFB0lWw-- Received: from [130.129.87.243] by web111405.mail.gq1.yahoo.com via HTTP; Wed, 27 Jul 2011 12:38:03 PDT X-Mailer: YahooMailRC/574 YahooMailWebService/0.8.112.310352 References: <000101cc48b3$a9f87500$fde95f00$@com> Message-ID: <1311795483.22406.YahooMailRC@web111405.mail.gq1.yahoo.com> Date: Wed, 27 Jul 2011 12:38:03 -0700 (PDT) From: Behcet Sarikaya To: Dan Wing , behave@ietf.org In-Reply-To: <000101cc48b3$a9f87500$fde95f00$@com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: draft-ietf-behave-nat64-learn-analysis@tools.ietf.org Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-nat64-learn-analysis-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 19:38:09 -0000 Hi, I have a comment for Section 4.9.1. I couldn't understand how the NAS entities would come to know the NSPs? Why is GTP not needed here? Regards, Behcet > > This starts a 3 week WGLC (extra time to accommodate IETF travel) for > draft-ietf-behave-nat64-learn-analysis-00. This document analyzes the > available approaches for a host to learn its NAT64 prefix. Abstract: > > Hosts and applications may benefit from the knowledge if an IPv6 > address is synthesized, which would mean a NAT64 is used to reach the > IPv4 network or Internet. This document analyses a number of > proposed solutions for communicating whether the synthesis is taking > place, used address format, and the IPv6 prefix used by the NAT64 and > DNS64. The solutions enable both NAT64 avoidance and intentional > utilization by allowing local IPv6 address synthesis. The document > concludes by recommending selection of heuristic discovery based > solution. > > Please send comments to behave@ietf.org. WGLC ends in 3 weeks on > August 12. > > -d > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From swmike@swm.pp.se Wed Jul 27 23:15:46 2011 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 F234A21F8B09 for ; Wed, 27 Jul 2011 23:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, 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 subpZvThK1xu for ; Wed, 27 Jul 2011 23:15:45 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 2558F21F8B08 for ; Wed, 27 Jul 2011 23:15:44 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id F0F2D9C; Thu, 28 Jul 2011 08:15:42 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id EC9F49A; Thu, 28 Jul 2011 08:15:42 +0200 (CEST) Date: Thu, 28 Jul 2011 08:15:42 +0200 (CEST) From: Mikael Abrahamsson To: Simon Perreault In-Reply-To: <4E1B4AE0.10006@viagenie.ca> Message-ID: References: <20110711190837.10592.63452.idtracker@ietfa.amsl.com> <4E1B4AE0.10006@viagenie.ca> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: behave@ietf.org Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-lsn-requirements-02.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: Thu, 28 Jul 2011 06:15:46 -0000 On Mon, 11 Jul 2011, Simon Perreault wrote: > o Better terminology for bulk port allocation mechanisms. I really really like that "bulk port allocation" is included. I would like it to be a SHOULD requirement. Having CGN handle tens of gigabit/s of normal Internet user traffic and trying to log 6 tuple (internal, external and destination ip/port) creates a huge amount of logging entries. In some markets we see existing or upcoming legal requirements to store logging data for years, so this creates a huge problem which as far as I can discern today, means the logging system actually becomes more expensive than the LSN device itself. Having bulk port allocation reduces the amount of logging by many magnitues (if one only logs the port allocation block creation and teardown, and requires any tracking/abuse report to include source port). I would also like to have included language that if I have 5000 users and 1000 external IP addresses, these 5000 users should be spread out over the pool so that the median of users per external IP address is close to 5 in this case. That means that for legal tracking, the legal entity can be given a list of 5 users even if one cannot say exactly which of the 5 did something at a certain time. I already know several vendors who have this feature in working code today, so having it described in a formal document would be beneficial to help bring more vendors to implement this behaviour. -- Mikael Abrahamsson email: swmike@swm.pp.se From bingxuere@gmail.com Thu Jul 28 00:46:38 2011 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 9CB8521F8B9C for ; Thu, 28 Jul 2011 00:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.548 X-Spam-Level: X-Spam-Status: No, score=-3.548 tagged_above=-999 required=5 tests=[AWL=0.050, 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 Nfc6duaCiXwA for ; Thu, 28 Jul 2011 00:46:37 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id BE4D521F8B93 for ; Thu, 28 Jul 2011 00:46:37 -0700 (PDT) Received: by iye7 with SMTP id 7so3147589iye.31 for ; Thu, 28 Jul 2011 00:46:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=Gd7qc8Z8bjanrHJ1qFKdMCVIxyZN+CJ1bL1+VcbGCag=; b=IG8SwSyZ0wZYxUD50vszKKMRXuV5fXGMKqpQEyltutF1gRvwExWqzQ74ghj4eyru38 jxrw9OzN2SfqiLv+OCBhT6pY1kFQ5HcyFhEIqigkvk2oniDoYKKa8Y7NZ4CwZqEG5t7u 6K5B8A6EnPRzFNyKSuiyo7k8cHSA0F7bdGvIU= Received: by 10.231.34.4 with SMTP id j4mr498860ibd.156.1311839197156; Thu, 28 Jul 2011 00:46:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.218.199 with HTTP; Thu, 28 Jul 2011 00:46:17 -0700 (PDT) From: Qiong Date: Thu, 28 Jul 2011 15:46:17 +0800 Message-ID: To: Fred Baker , ssenthil@cisco.com, behave@ietf.org Content-Type: multipart/alternative; boundary=0022154012fa5956ca04a91c5df8 Subject: [BEHAVE] comments on logging of NAT Events 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: Thu, 28 Jul 2011 07:46:38 -0000 --0022154012fa5956ca04a91c5df8 Content-Type: text/plain; charset=UTF-8 Dear Fred, all, With regard to NAT logging requirements, I think the listed tuple in this draft is quite enough for our traceablity . However, since our major difficulty is how to the handle huge amount of NAT logging event in a centralized log server, we would like the logging event to be as simple as possible. In our deployment model, logging server is usually deployed at higher level than LSN. This means it has to handle session-based logging events generated by tens of gigabit/s of Internet traffic, not to mention that we even have to store them for months. This would not only bring a great burden on logging server, but also it would be quite expensive. So, we prefer to store customer-based logging event (only include IPv6 address, postNATSourceIPv4Address, port range, and timestamp), rather than session-based logging. Although most vendors we have tested already support this feature, their data formats are quite different. I strongly agree that NAT logging should be standardized in the near future. Moreover, I'm wondering why do we need to have BIB create/delete logging event. What does it designed for in case we already have session create/delete event? Maybe I have missed something during the behave meeting. Please correct me if I missed something. :-) Best wishes Qiong Sun ---------- Forwarded message ---------- From: Fred Baker To: IPv6 Operations Date: Wed, 27 Jul 2011 16:29:51 -0400 Subject: [v6ops] Requirements for logging in NAT44, NAT64, and NPTv6 This afternoon, in behave, there was a brief discussion of NAT logging. behave has a draft in progress, but has no real idea how it relates to enterprise or service provider logging requirements. What would really help would be for network operators with NAT logging requirements (most likely broadband service providers, mobile service providers, and educational or enterprise networks with similar requirements) to review the draft and comment to behave@ietf.org. The draft is http://tools.ietf.org/html/draft-sivakumar-behave-nat-logging "Logging of NAT Events", Senthil Sivakumar, Reinaldo Penno, 13-Jul-11 My perception is that the primary NAT logging requirements derive from forensic requirements, and potentially differ based on regional or national requirements - important requirement sets include US, European, Australian, Japanese, and Chinese directives. I would summarize them in this way: - With stateless NAT64, I don't think there is a need for translation logging, as it is statelessly predictable. - There are legal requirements around logging for NAT44 and stateful NAT64, primarily around forensic requirements. I believe that comes down to, when configured, a message with a timestamp, an interface identifier, and an address/port (IPv4 or IPv6) four-or-five-tuple. Given that this would happen on the first packet to cross the NAT, there would be no data retention capability in the same message - data retention requirements for NAT44, stateful NAT64, and stateless NAT64 would have to be met by IPFIX, much as they are now. It probably also implies a statement that this is Internet layer information; one cannot expect it to come up with email addresses, URLs, instant messaging handles, or other wishful thinking we have read in ill-informed legal documents. This implies a capability (tool) to interpret the two databases in response to legal inquiries. --0022154012fa5956ca04a91c5df8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Fred, all,

With regard to NAT logging requirements,= I think the listed tuple in this draft is quite enough for our traceablity= . However, since our major difficulty is how to the handle huge amount of = NAT logging event in a centralized log server, we would like the logging ev= ent to be as simple as possible.=C2=A0

In our deployment model, logging server is usually depl= oyed at higher level than LSN. This means it has to handle session-based lo= gging events generated by tens of=C2=A0gigabit/s of Internet tra= ffic, not to mention that we even have to store them for months.=C2= =A0This would not only bring a great burden on logging server, but also it = would be quite expensive. So, we prefer to store customer-based logging eve= nt (only include IPv6 address, postNATSourceIPv4Address, port range, and ti= mestamp), rather than session-based logging. =C2=A0Although most vendors we= have tested already support this feature, their data formats are quite dif= ferent. I strongly agree that NAT logging should be standardized in the nea= r future.=C2=A0

Moreover, I'm wondering why do we need to have= BIB create/delete logging event. What does it designed for in case we alre= ady have session create/delete event?

Maybe I have= missed something during the behave meeting.=C2=A0Please correct me if I mi= ssed something. :-)

Best wishes

Qiong Sun


---------- Forwarded message ---= -------
From:=C2=A0Fred Baker <fred@cisco.com>
To:=C2=A0IPv6 Operations <v6ops@ietf.org>
Date:=C2=A0Wed= , 27 Jul 2011 16:29:51 -0400
Subject:=C2=A0[v6ops] Requirements for logging in NAT44, NAT64, and NPTv6 This afternoon, in behave, there was a brief discussion of NAT logging. beh= ave has a draft in progress, but has no real idea how it relates to enterpr= ise or service provider logging requirements. What would really help would = be for network operators with NAT logging requirements (most likely broadba= nd service providers, mobile service providers, and educational or enterpri= se networks with similar requirements) to review the draft and comment to= =C2=A0behave@ietf.org.

The draft is=C2=A0htt= p://tools.ietf.org/html/draft-sivakumar-behave-nat-logging
=C2=A0&qu= ot;Logging of NAT Events", Senthil Sivakumar, Reinaldo Penno, 13-Jul-1= 1

My perception is that the primary NAT logging requirements derive from = forensic requirements, and potentially differ based on regional or national= requirements - important requirement sets include US, European, Australian= , Japanese, and Chinese directives. I would summarize them in this way:

=C2=A0- With stateless NAT64, I don't think there is a need for tra= nslation logging, as it is statelessly predictable.

=C2=A0- There ar= e legal requirements around logging for NAT44 and stateful NAT64, primarily= around forensic requirements. I believe that comes down to, when configure= d, a message with a timestamp, an interface identifier, and an address/port= (IPv4 or IPv6) four-or-five-tuple. Given that this would happen on the fir= st packet to cross the NAT, there would be no data retention capability in = the same message - data retention requirements for NAT44, stateful NAT64, a= nd stateless NAT64 would have to be met by IPFIX, much as they are now.

It probably also implies a statement that this is Internet layer inform= ation; one cannot expect it to come up with email addresses, URLs, instant = messaging handles, or other wishful thinking we have read in ill-informed l= egal documents.

This implies a capability (tool) to interpret the two databases in resp= onse to legal inquiries.
--0022154012fa5956ca04a91c5df8-- From jouni.nospam@gmail.com Thu Jul 28 07:59:50 2011 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 5F4C221F8BA2 for ; Thu, 28 Jul 2011 07:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.905 X-Spam-Level: X-Spam-Status: No, score=-2.905 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, 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 1y5KnO6ATzSu for ; Thu, 28 Jul 2011 07:59:49 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id C603521F8B2C for ; Thu, 28 Jul 2011 07:59:49 -0700 (PDT) Received: by yie30 with SMTP id 30so2281443yie.31 for ; Thu, 28 Jul 2011 07:59:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=FW9TWQQ/Bdcqwqzz3r/Ef3I3j5YgVKUUykBbu8MMUjY=; b=haG0qexREtZIojtJSpfvDBdnEAi5vowaKhCmqd2+FpXdP0ovdWMKkVvv+do5rgNyWs F+NhM/8zRH2+d6e7vkNxADkYWvLEgyUgmJiKPE8ITMMfq7EVxNtqf+45E+VlBUSanyiA 6siXL7GUJPYMPn3H0JJaRe36/3sjw1f08iXjA= Received: by 10.204.7.3 with SMTP id b3mr36938bkb.262.1311865186279; Thu, 28 Jul 2011 07:59:46 -0700 (PDT) Received: from [62.237.209.78] ([62.237.209.78]) by mx.google.com with ESMTPS id l22sm307571bku.57.2011.07.28.07.59.36 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Jul 2011 07:59:45 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <1311795483.22406.YahooMailRC@web111405.mail.gq1.yahoo.com> Date: Thu, 28 Jul 2011 17:59:19 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <000101cc48b3$a9f87500$fde95f00$@com> <1311795483.22406.YahooMailRC@web111405.mail.gq1.yahoo.com> To: Behcet Sarikaya X-Mailer: Apple Mail (2.1084) Cc: behave@ietf.org, draft-ietf-behave-nat64-learn-analysis@tools.ietf.org, Dan Wing Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-nat64-learn-analysis-00 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: Thu, 28 Jul 2011 14:59:50 -0000 On Jul 27, 2011, at 10:38 PM, Behcet Sarikaya wrote: > Hi, > I have a comment for Section 4.9.1.=20 > I couldn't understand how the NAS entities would come to know the = NSPs?=20 > Why is GTP not needed here? Does it really matter here? Non-Access-Stratum (NAS) signaling was given = as an example of an existing transport/container how to get the required = information into the end host on a specific link type. We could use = IPV6CP in case of PPP etc. Where the configuration information = originates is secondary as long as it passed around to relevant element = in a _system_specific_ means. In EPS case that would probably involve a = non-trivial combination of NAS, AAA and GTP-C/PMIPv6 signaling. See the = first CON in Section 4.9.2 about the downside of the Section 4.9.1 = approach. - Jouni >=20 > Regards, >=20 > Behcet >=20 >=20 >>=20 >> This starts a 3 week WGLC (extra time to accommodate IETF travel) = for >> draft-ietf-behave-nat64-learn-analysis-00. This document analyzes = the >> available approaches for a host to learn its NAT64 prefix. = Abstract: >>=20 >> Hosts and applications may benefit from the knowledge if an IPv6 >> address is synthesized, which would mean a NAT64 is used to reach = the >> IPv4 network or Internet. This document analyses a number of >> proposed solutions for communicating whether the synthesis is = taking >> place, used address format, and the IPv6 prefix used by the NAT64 = and >> DNS64. The solutions enable both NAT64 avoidance and intentional >> utilization by allowing local IPv6 address synthesis. The = document >> concludes by recommending selection of heuristic discovery based >> solution. >>=20 >> Please send comments to behave@ietf.org. WGLC ends in 3 weeks on=20 >> August 12. >>=20 >> -d >>=20 >>=20 >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >>=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From ssenthil@cisco.com Thu Jul 28 10:32:54 2011 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 56F6421F8C17 for ; Thu, 28 Jul 2011 10:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.865 X-Spam-Level: X-Spam-Status: No, score=0.865 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_NUMERIC_HELO=2.067] 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 HJWLgWfzlvZr for ; Thu, 28 Jul 2011 10:32:51 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 5931321F8B8F for ; Thu, 28 Jul 2011 10:32:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ssenthil@cisco.com; l=10646; q=dns/txt; s=iport; t=1311874361; x=1313083961; h=date:subject:from:to:message-id:in-reply-to:mime-version; bh=FN6bBYMMsD4zO1tZAX4NBKmIzHHm/qqXcOsf8Zvg3n0=; b=FIdzkMq7ltAL1/CdV/MwnmEyMORauTgtHD69sD7i86fX8uWHEisZYZYO aZDgopOenjBLxdBpBsytXbnBbH+R0D/eNVxkTboPDsMXtDjUdEuCvOxvN Vdm3LzreuIMgkJvVVbeEjeFvytFBM8NS2MtXf+l+10b0mpAgrBrBTgFaY k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwHAAicMU6rRDoI/2dsb2JhbAA0AQEBAQIBFAEvRg4BCQkIAwECTxI3CAEBBQEWJ4I2nGaHNWcCd4h8BKQGnk+GQQSHKotPhRCEW4cV X-IronPort-AV: E=Sophos;i="4.67,283,1309737600"; d="scan'208,217";a="7466193" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-8.cisco.com with ESMTP; 28 Jul 2011 17:32:40 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6SHWTTF015021; Thu, 28 Jul 2011 17:32:40 GMT Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Jul 2011 10:32:39 -0700 Received: from 64.102.207.141 ([64.102.207.141]) by xmb-sjc-236.amer.cisco.com ([128.107.191.121]) with Microsoft Exchange Server HTTP-DAV ; Thu, 28 Jul 2011 17:32:38 +0000 User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Thu, 28 Jul 2011 13:32:36 -0400 From: ssenthil To: Qiong , Fred Baker , Message-ID: Thread-Topic: [BEHAVE]comments on logging of NAT Events Thread-Index: AcxNTFcJ6fPlRkVL3U6TE6P4WojMZQ== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3394704756_10775305" X-OriginalArrivalTime: 28 Jul 2011 17:32:39.0021 (UTC) FILETIME=[58D689D0:01CC4D4C] Subject: Re: [BEHAVE] comments on logging of NAT Events 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: Thu, 28 Jul 2011 17:32:54 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3394704756_10775305 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Please see inline. On 7/28/11 3:46 AM, "Qiong" wrote: > Dear Fred, all, >=20 > With regard to NAT logging requirements, I think the listed tuple in this > draft is quite enough for our traceablity . However, since our major > difficulty is how to the handle huge amount of NAT logging event in a > centralized log server, we would like the logging event to be as simple a= s > possible.=A0 >=20 > [Senthil] I think this is the challenge on how to optimize the data being > logged as there are different ideas and different requirements surroundin= g the > optimization. That=B9s why this draft does not address the optimization > techniques but just standardizing the formats and leave it up to the > individual implementations to optimize it. >=20 > In our deployment model, logging server is usually deployed at higher lev= el > than LSN. This means it has to handle session-based logging events genera= ted > by tens of=A0gigabit/s of Internet traffic, not to mention that we even hav= e to > store them for months.=A0This would not only bring a great burden on loggin= g > server, but also it would be quite expensive. So, we prefer to store > customer-based logging event (only include IPv6 address, > postNATSourceIPv4Address, port range, and timestamp), rather than > session-based logging. =A0Although most vendors we have tested already supp= ort > this feature, their data formats are quite different. I strongly agree th= at > NAT logging should be standardized in the near future.=A0 >=20 > [Senthil] Ok, good. >=20 > Moreover, I'm wondering why do we need to have BIB create/delete logging > event. What does it designed for in case we already have session create/d= elete > event? >=20 > [Senthil] Not all implementations do create sessions, most CGN implementa= tions > have only BIB entries (without the destination address/port information).= The > BIB create/delete events will be used in those circumstances. When you ha= ve a > BIB entry, you would be able to log the destination information at the ti= me of > creation but not at the time of deletion. >=20 > Maybe I have missed something during the behave meeting.=A0Please correct m= e if > I missed something. :-) >=20 > Best wishes >=20 > Qiong Sun >=20 >=20 > ---------- Forwarded message ---------- > From:=A0Fred Baker > To:=A0IPv6 Operations > Date:=A0Wed, 27 Jul 2011 16:29:51 -0400 > Subject:=A0[v6ops] Requirements for logging in NAT44, NAT64, and NPTv6 > This afternoon, in behave, there was a brief discussion of NAT logging. b= ehave > has a draft in progress, but has no real idea how it relates to enterpris= e or > service provider logging requirements. What would really help would be fo= r > network operators with NAT logging requirements (most likely broadband se= rvice > providers, mobile service providers, and educational or enterprise networ= ks > with similar requirements) to review the draft and comment to=A0behave@ietf= .org. >=20 > The draft is=A0http://tools.ietf.org/html/draft-sivakumar-behave-nat-loggin= g > =A0"Logging of NAT Events", Senthil Sivakumar, Reinaldo Penno, 13-Jul-11 >=20 > My perception is that the primary NAT logging requirements derive from > forensic requirements, and potentially differ based on regional or nation= al > requirements - important requirement sets include US, European, Australia= n, > Japanese, and Chinese directives. I would summarize them in this way: >=20 > =A0- With stateless NAT64, I don't think there is a need for translation > logging, as it is statelessly predictable. >=20 > =A0- There are legal requirements around logging for NAT44 and stateful NAT= 64, > primarily around forensic requirements. I believe that comes down to, whe= n > configured, a message with a timestamp, an interface identifier, and an > address/port (IPv4 or IPv6) four-or-five-tuple. Given that this would hap= pen > on the first packet to cross the NAT, there would be no data retention > capability in the same message - data retention requirements for NAT44, > stateful NAT64, and stateless NAT64 would have to be met by IPFIX, much a= s > they are now. >=20 > It probably also implies a statement that this is Internet layer informat= ion; > one cannot expect it to come up with email addresses, URLs, instant messa= ging > handles, or other wishful thinking we have read in ill-informed legal > documents. >=20 > This implies a capability (tool) to interpret the two databases in respon= se to > legal inquiries. >=20 --B_3394704756_10775305 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [BEHAVE]comments on logging of NAT Events Please see inline.


On 7/28/11 3:46 AM, "Qiong" <bin= gxuere@gmail.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>Dear Fred, all,

With regard to NAT logging requirements, I think the listed tuple in this d= raft is quite enough for our traceablity . However, since our major difficul= ty is how to the handle huge amount of NAT logging event in a centralized lo= g server, we would like the logging event to be as simple as possible.=A0

[Senthil] I think this is the challenge on how to optimize the data being l= ogged as there are different ideas and different requirements surrounding th= e optimization. That’s why this draft does not address the optimizatio= n techniques but just standardizing the formats and leave it up to the indiv= idual implementations to optimize it.

In our deployment model, logging server is usually deployed at higher level= than LSN. This means it has to handle session-based logging events generate= d by tens of=A0gigabit/s of Internet traffic, not to mention that we even hav= e to store them for months.=A0This would not only bring = a great burden on logging server, but also it would be quite expensive. So, = we prefer to store customer-based logging event (only include IPv6 address, = postNATSourceIPv4Address, port range, and timestamp), rather than session-ba= sed logging. =A0Although most vendors we have tested already support this feat= ure, their data formats are quite different. I strongly agree that NAT loggi= ng should be standardized in the near future.=A0

[Senthil] Ok, good.

Moreover, I'm wondering why do we need to have BIB create/delete logging ev= ent. What does it designed for in case we already have session create/delete= event?

[Senthil] Not all implementations do create sessions, most CGN implementati= ons have only BIB entries (without the destination address/port information)= . The BIB create/delete events will be used in those circumstances. When you= have a BIB entry, you would be able to log the destination information at t= he time of creation but not at the time of deletion.

Maybe I have missed something during the behave meeting.=A0Please correct me = if I missed something. :-)

Best wishes

Qiong Sun


---------- Forwarded message ----------
From:=A0Fred Baker <fred@cisco.com>
To:=A0IPv6 Operations <v6ops@ietf.org>
Date:=A0Wed, 27 Jul 2011 16:29:51 -0400
Subject:=A0[v6ops] Requirements for logging in NAT44, NAT64, and NPTv6
This afternoon, in behave, there was a brief discussion of NAT logging. beh= ave has a draft in progress, but has no real idea how it relates to enterpri= se or service provider logging requirements. What would really help would be= for network operators with NAT logging requirements (most likely broadband = service providers, mobile service providers, and educational or enterprise n= etworks with similar requirements) to review the draft and comment to=A0behave@ietf.org.

The draft is=A0http://tools.ietf.org/html/draft-sivakumar-behave-nat-logging<= BR> =A0"Logging of NAT Events", Senthil Sivakumar, Reinaldo Penno, 13-J= ul-11

My perception is that the primary NAT logging requirements derive from fore= nsic requirements, and potentially differ based on regional or national requ= irements - important requirement sets include US, European, Australian, Japa= nese, and Chinese directives. I would summarize them in this way:

=A0- With stateless NAT64, I don't think there is a need for translation logg= ing, as it is statelessly predictable.

=A0- There are legal requirements around logging for NAT44 and stateful NAT64= , primarily around forensic requirements. I believe that comes down to, when= configured, a message with a timestamp, an interface identifier, and an add= ress/port (IPv4 or IPv6) four-or-five-tuple. Given that this would happen on= the first packet to cross the NAT, there would be no data retention capabil= ity in the same message - data retention requirements for NAT44, stateful NA= T64, and stateless NAT64 would have to be met by IPFIX, much as they are now= .

It probably also implies a statement that this is Internet layer informatio= n; one cannot expect it to come up with email addresses, URLs, instant messa= ging handles, or other wishful thinking we have read in ill-informed legal d= ocuments.

This implies a capability (tool) to interpret the two databases in response= to legal inquiries.

--B_3394704756_10775305-- From behcetsarikaya@yahoo.com Thu Jul 28 13:21:23 2011 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 DAE8D11E8083 for ; Thu, 28 Jul 2011 13:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.861 X-Spam-Level: X-Spam-Status: No, score=-1.861 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, J_CHICKENPOX_32=0.6] 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 tyEf5xDTSLCr for ; Thu, 28 Jul 2011 13:21:22 -0700 (PDT) Received: from nm18.bullet.mail.sp2.yahoo.com (nm18.bullet.mail.sp2.yahoo.com [98.139.91.88]) by ietfa.amsl.com (Postfix) with SMTP id 65DF211E80E3 for ; Thu, 28 Jul 2011 13:21:22 -0700 (PDT) Received: from [98.139.91.67] by nm18.bullet.mail.sp2.yahoo.com with NNFMP; 28 Jul 2011 20:21:22 -0000 Received: from [98.139.91.39] by tm7.bullet.mail.sp2.yahoo.com with NNFMP; 28 Jul 2011 20:21:22 -0000 Received: from [127.0.0.1] by omp1039.mail.sp2.yahoo.com with NNFMP; 28 Jul 2011 20:21:22 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 352286.84267.bm@omp1039.mail.sp2.yahoo.com Received: (qmail 90299 invoked by uid 60001); 28 Jul 2011 20:21:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1311884482; bh=An24gJ4BE/dj/U2NXl7LFOugeGiuZxCpNGFfQXaDycs=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=QgA2WU8q8mbYd2TrOCGePGA06FTcK6WYOM0OwKFFd6zHcPnDfgTdYtdSeXmpNWvTxUINdgwVTMC/MMi4YqskTFolIrHykeGGnE6vBbkh4jeIOThlAGH4RbdyzFRgoY/v7I+CmWjuqVReH948F+20fKgpc0+fc1LUFjQyqEnBems= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ZD/9e/p//rLEm1DZrUnVEd3siiQcTzi4ifrayNz9oE2cc99dV4XQA/7CPKYh4eLG/4b1+0gvC8dGRCofCynV9BXUwNTZi3EaEQBBogVYkGKJVdK1/coTae8rnLgnvsdSmxVvSkRBJwU4r+eF5bx++h8dFDPLqgYDY4G6FmdhvB8=; X-YMail-OSG: 1854YEgVM1m5Mc5E6zXf.Z_cjvqRJxYniY9oFN.6W4gI1rB GLxGY6Ne.T70ES6r4vwPSmTipM_ziW_diCrG6NNTmbmMXoYpaS694H.hS9iE NdXOdyZ.tamyRhE2qQ6GjNm995jb1g_fUoT42VYGDrwj1nVZRrVZi9Yp54sq .brqy_enzh9nL4S2DyBafPh5uAzZdTesej4nfxGy3.0EoEQJ5VX8V85mLBiY EniMi1O6torCx1MkyzlNrcH7TeQsqAYHeTjXRQZBYfLvfl_v12A.TcwFOT15 a_ClzZCdYhw93Jcv7bvYsGacvJD_R84vMPs_SZYniboDo1r5jsiwZmQBnlKd pLwXYsHwNxkMaj.mcfDwNqYihMCxuX43L_cJMFebzqS80CB7kVasAvXeyJeD OLzfOShbyhGmVcA-- Received: from [130.129.87.243] by web111404.mail.gq1.yahoo.com via HTTP; Thu, 28 Jul 2011 13:21:21 PDT X-Mailer: YahooMailRC/574 YahooMailWebService/0.8.112.310352 References: <000101cc48b3$a9f87500$fde95f00$@com> <1311795483.22406.YahooMailRC@web111405.mail.gq1.yahoo.com> Message-ID: <1311884481.75819.YahooMailRC@web111404.mail.gq1.yahoo.com> Date: Thu, 28 Jul 2011 13:21:21 -0700 (PDT) From: Behcet Sarikaya To: jouni korhonen In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: behave@ietf.org, draft-ietf-behave-nat64-learn-analysis@tools.ietf.org, Dan Wing Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-nat64-learn-analysis-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 20:21:23 -0000 > > Hi, > > I have a comment for Section 4.9.1. > > I couldn't understand how the NAS entities would come to know the NSPs? > > Why is GTP not needed here? > > Does it really matter here? Non-Access-Stratum (NAS) signaling was given as an >example of an existing transport/container how to get the required information >into the end host on a specific link type. We could use IPV6CP in case of PPP >etc. Where the configuration information originates is secondary as long as it >passed around to relevant element in a _system_specific_ means. In EPS case >that would probably involve a non-trivial combination of NAS, AAA and >GTP-C/PMIPv6 signaling. > For the sake of giving a complete view of what is needed, including the above (or some similar text) in the draft would be good. Behcet >See the first CON in Section 4.9.2 about the downside of the Section 4.9.1 >approach. > > > - Jouni > > > > > > > Regards, > > > > Behcet > > > > > >> > >> This starts a 3 week WGLC (extra time to accommodate IETF travel) for > >> draft-ietf-behave-nat64-learn-analysis-00. This document analyzes the > >> available approaches for a host to learn its NAT64 prefix. Abstract: > >> > >> Hosts and applications may benefit from the knowledge if an IPv6 > >> address is synthesized, which would mean a NAT64 is used to reach the > >> IPv4 network or Internet. This document analyses a number of > >> proposed solutions for communicating whether the synthesis is taking > >> place, used address format, and the IPv6 prefix used by the NAT64 and > >> DNS64. The solutions enable both NAT64 avoidance and intentional > >> utilization by allowing local IPv6 address synthesis. The document > >> concludes by recommending selection of heuristic discovery based > >> solution. > >> > >> Please send comments to behave@ietf.org. WGLC ends in 3 weeks on > >> August 12. > >> > >> -d > >> > >> > >> _______________________________________________ > >> Behave mailing list > >> Behave@ietf.org > >> https://www.ietf.org/mailman/listinfo/behave > >> > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > > From jouni.nospam@gmail.com Thu Jul 28 15:27:44 2011 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 02B1321F87D9 for ; Thu, 28 Jul 2011 15:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.924 X-Spam-Level: X-Spam-Status: No, score=-2.924 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, 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 MYEMsK4WjlBQ for ; Thu, 28 Jul 2011 15:27:43 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 15E5D21F877F for ; Thu, 28 Jul 2011 15:27:42 -0700 (PDT) Received: by fxe6 with SMTP id 6so1891097fxe.31 for ; Thu, 28 Jul 2011 15:27:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=m3RIxAvwWnjNI/E+YvfEE6umJ8kJvWirB6H5euM5eSo=; b=ttblgIhlg69oEnO8VwhX6RFeFVgFDAUajqqFhEtCBGuN1l1uZM8NVAf8Gt+HusrHFA 5jWkF+Z1dsMXM3JhS7mflch87pJKDB/vT/wRxo1vBVM0HDK3lpnXxX9ImUDcxAmYBzuz d41w9AQpBxEGDJ/KoGMVuImO9OoGOlmdPSYuU= Received: by 10.204.191.79 with SMTP id dl15mr163686bkb.269.1311892062034; Thu, 28 Jul 2011 15:27:42 -0700 (PDT) Received: from [62.237.209.66] ([62.237.209.66]) by mx.google.com with ESMTPS id t19sm398859bku.7.2011.07.28.15.26.57 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Jul 2011 15:27:40 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <1311884481.75819.YahooMailRC@web111404.mail.gq1.yahoo.com> Date: Fri, 29 Jul 2011 01:25:42 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <000101cc48b3$a9f87500$fde95f00$@com> <1311795483.22406.YahooMailRC@web111405.mail.gq1.yahoo.com> <1311884481.75819.YahooMailRC@web111404.mail.gq1.yahoo.com> To: Behcet Sarikaya X-Mailer: Apple Mail (2.1084) Cc: behave@ietf.org, draft-ietf-behave-nat64-learn-analysis@tools.ietf.org, Dan Wing Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-nat64-learn-analysis-00 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: Thu, 28 Jul 2011 22:27:44 -0000 On Jul 28, 2011, at 11:21 PM, Behcet Sarikaya wrote: >>>=20 >>> Hi, >>> I have a comment for Section 4.9.1.=20 >>> I couldn't understand how the NAS entities would come to know the = NSPs?=20 >>> Why is GTP not needed here? >>=20 >> Does it really matter here? Non-Access-Stratum (NAS) signaling was = given as an=20 >> example of an existing transport/container how to get the required = information=20 >> into the end host on a specific link type. We could use IPV6CP in = case of PPP=20 >> etc. Where the configuration information originates is secondary as = long as it=20 >> passed around to relevant element in a _system_specific_ means. In = EPS case=20 >> that would probably involve a non-trivial combination of NAS, AAA = and=20 >> GTP-C/PMIPv6 signaling.=20 >>=20 >=20 >=20 > For the sake of giving a complete view of what is needed, including = the above=20 > (or some similar text) in the draft would be good. Ok. I'll figure out something and post it later on the list. - JOuni >=20 >=20 > Behcet >> See the first CON in Section 4.9.2 about the downside of the Section = 4.9.1=20 >> approach. >>=20 >>=20 >> - Jouni >>=20 >>=20 >>=20 >>>=20 >>> Regards, >>>=20 >>> Behcet >>>=20 >>>=20 >>>>=20 >>>> This starts a 3 week WGLC (extra time to accommodate IETF travel) = for >>>> draft-ietf-behave-nat64-learn-analysis-00. This document analyzes = the >>>> available approaches for a host to learn its NAT64 prefix. = Abstract: >>>>=20 >>>> Hosts and applications may benefit from the knowledge if an = IPv6 >>>> address is synthesized, which would mean a NAT64 is used to = reach the >>>> IPv4 network or Internet. This document analyses a number of >>>> proposed solutions for communicating whether the synthesis is = taking >>>> place, used address format, and the IPv6 prefix used by the = NAT64 and >>>> DNS64. The solutions enable both NAT64 avoidance and = intentional >>>> utilization by allowing local IPv6 address synthesis. The = document >>>> concludes by recommending selection of heuristic discovery based >>>> solution. >>>>=20 >>>> Please send comments to behave@ietf.org. WGLC ends in 3 weeks on=20= >>>> August 12. >>>>=20 >>>> -d >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Behave mailing list >>>> Behave@ietf.org >>>> https://www.ietf.org/mailman/listinfo/behave >>>>=20 >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >>=20 >>=20 From jouni.nospam@gmail.com Thu Jul 28 20:42:11 2011 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 EBC9811E807F for ; Thu, 28 Jul 2011 20:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.277 X-Spam-Level: X-Spam-Status: No, score=-3.277 tagged_above=-999 required=5 tests=[AWL=-0.322, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, J_CHICKENPOX_32=0.6, 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 6ErFoQGjf+kb for ; Thu, 28 Jul 2011 20:42:11 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 4F73111E8075 for ; Thu, 28 Jul 2011 20:42:11 -0700 (PDT) Received: by qyk29 with SMTP id 29so2097493qyk.10 for ; Thu, 28 Jul 2011 20:42:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=gRDxeX+PDcu39sOFj/pk2X+JLCBYEG+OI08s4o5yNkU=; b=LGFkWIT3KuZNTbf7FAMjUxBCr+jnPPUqk4m6wSNCuBW79orhfwr3PsU8f6SPejuUbR v7pwfpVMtgOFrCPuDRqji2I2t9TN2xjovdMqNqtWwf19LA+056a0SPaOSTiCafaqTk8y SpqNKR043fucFQAwYhSZ0EhY6RVgzdjfjP9/8= Received: by 10.224.108.66 with SMTP id e2mr709050qap.41.1311910930602; Thu, 28 Jul 2011 20:42:10 -0700 (PDT) Received: from dhcp-43d8.meeting.ietf.org (dhcp-43d8.meeting.ietf.org [130.129.67.216]) by mx.google.com with ESMTPS id p15sm1156360qct.10.2011.07.28.20.42.09 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Jul 2011 20:42:10 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <1311884481.75819.YahooMailRC@web111404.mail.gq1.yahoo.com> Date: Fri, 29 Jul 2011 01:27:54 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <000101cc48b3$a9f87500$fde95f00$@com> <1311795483.22406.YahooMailRC@web111405.mail.gq1.yahoo.com> <1311884481.75819.YahooMailRC@web111404.mail.gq1.yahoo.com> To: Behcet Sarikaya X-Mailer: Apple Mail (2.1084) Cc: behave@ietf.org, draft-ietf-behave-nat64-learn-analysis@tools.ietf.org, Dan Wing Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-nat64-learn-analysis-00 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, 29 Jul 2011 03:42:12 -0000 On Jul 28, 2011, at 11:21 PM, Behcet Sarikaya wrote: >>>=20 >>> Hi, >>> I have a comment for Section 4.9.1.=20 >>> I couldn't understand how the NAS entities would come to know the = NSPs?=20 >>> Why is GTP not needed here? >>=20 >> Does it really matter here? Non-Access-Stratum (NAS) signaling was = given as an=20 >> example of an existing transport/container how to get the required = information=20 >> into the end host on a specific link type. We could use IPV6CP in = case of PPP=20 >> etc. Where the configuration information originates is secondary as = long as it=20 >> passed around to relevant element in a _system_specific_ means. In = EPS case=20 >> that would probably involve a non-trivial combination of NAS, AAA = and=20 >> GTP-C/PMIPv6 signaling.=20 >>=20 >=20 >=20 > For the sake of giving a complete view of what is needed, including = the above=20 > (or some similar text) in the draft would be good. Ok. I'll figure out something and post it later on the list. - JOuni >=20 >=20 > Behcet >> See the first CON in Section 4.9.2 about the downside of the Section = 4.9.1=20 >> approach. >>=20 >>=20 >> - Jouni >>=20 >>=20 >>=20 >>>=20 >>> Regards, >>>=20 >>> Behcet >>>=20 >>>=20 >>>>=20 >>>> This starts a 3 week WGLC (extra time to accommodate IETF travel) = for >>>> draft-ietf-behave-nat64-learn-analysis-00. This document analyzes = the >>>> available approaches for a host to learn its NAT64 prefix. = Abstract: >>>>=20 >>>> Hosts and applications may benefit from the knowledge if an IPv6 >>>> address is synthesized, which would mean a NAT64 is used to reach = the >>>> IPv4 network or Internet. This document analyses a number of >>>> proposed solutions for communicating whether the synthesis is = taking >>>> place, used address format, and the IPv6 prefix used by the NAT64 = and >>>> DNS64. The solutions enable both NAT64 avoidance and intentional >>>> utilization by allowing local IPv6 address synthesis. The = document >>>> concludes by recommending selection of heuristic discovery based >>>> solution. >>>>=20 >>>> Please send comments to behave@ietf.org. WGLC ends in 3 weeks on=20= >>>> August 12. >>>>=20 >>>> -d >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Behave mailing list >>>> Behave@ietf.org >>>> https://www.ietf.org/mailman/listinfo/behave >>>>=20 >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >>=20 >>=20 From yiu_lee@cable.comcast.com Sat Jul 30 18:23:11 2011 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 769C521F861E for ; Sat, 30 Jul 2011 18:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.407 X-Spam-Level: X-Spam-Status: No, score=-102.407 tagged_above=-999 required=5 tests=[AWL=-0.673, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 gd2z77al4NXM for ; Sat, 30 Jul 2011 18:23:10 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id B5A9B21F85B2 for ; Sat, 30 Jul 2011 18:23:10 -0700 (PDT) Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.46856976; Sat, 30 Jul 2011 19:28:02 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0289.001; Sat, 30 Jul 2011 21:23:09 -0400 From: "Lee, Yiu" To: "behave@ietf.org" Thread-Topic: draft-boucadair-behave-64-multicast-address-format-02 Thread-Index: AQHMTyBnr12cZQhVH06FGdFez2RqSQ== Date: Sun, 31 Jul 2011 01:23:08 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [69.253.6.2] Content-Type: multipart/alternative; boundary="_000_CA5A26BB12E61yiuleecablecomcastcom_" MIME-Version: 1.0 Subject: [BEHAVE] draft-boucadair-behave-64-multicast-address-format-02 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, 31 Jul 2011 01:23:11 -0000 --_000_CA5A26BB12E61yiuleecablecomcastcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi WG, We wrote a draft to describe how to map an IPv4 multicast group address int= o an IPv6 multicast group address. This mechanism is needed for http://tool= s.ietf.org/html/draft-xu-softwire-mesh-multicast-02 and http://tools.ietf.o= rg/html/draft-qin-softwire-dslite-multicast-04. http://tools.ietf.org/html/draft-qin-softwire-dslite-multicast-04 has been = accepted in Software a WG item. Software WG is also considering to adopt ht= tp://tools.ietf.org/html/draft-qin-softwire-dslite-multicast-04. We would l= ike to ask the WG to review the http://tools.ietf.org/html/draft-boucadair-= behave-64-multicast-address-format-02 and give us comments and feedback. We= will need this draft to complete the work in multicast designs in Software= WG. Thanks, Yiu --_000_CA5A26BB12E61yiuleecablecomcastcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <3DC2A2CBE58B3A4BB938736713CEEEC5@cable.comcast.com> Content-Transfer-Encoding: quoted-printable
Hi WG,

We wrote a draft to describe how to map an IPv4 multicast group addres= s into an IPv6 multicast group address. This mechanism is needed for <= a href=3D"http://tools.ietf.org/html/draft-xu-softwire-mesh-multicast-02">h= ttp://tools.ietf.org/html/draft-xu-softwire-mesh-multicast-02 and&= nbsp;http://tools.ietf.org/html/draft-qin-softwire-dslite-multicast-04. 

Thanks,
Yiu


--_000_CA5A26BB12E61yiuleecablecomcastcom_--