From teemu.savolainen@nokia.com Wed Jun 1 02:01: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 E35A1E07A6 for ; Wed, 1 Jun 2011 02:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.742 X-Spam-Level: X-Spam-Status: No, score=-2.742 tagged_above=-999 required=5 tests=[AWL=-0.143, 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 qvBD3yY2e3RG for ; Wed, 1 Jun 2011 02:01:30 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 55383E07A1 for ; Wed, 1 Jun 2011 02:01:30 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p5191Kw4027836; Wed, 1 Jun 2011 12:01:26 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 1 Jun 2011 12:01:24 +0300 Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 1 Jun 2011 11:01:24 +0200 Received: from 008-AM1MPN1-036.mgdnok.nokia.com ([169.254.6.209]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0289.008; Wed, 1 Jun 2011 11:01:23 +0200 From: To: , Thread-Topic: [BEHAVE] Next for draft-ietf-behave-nat64-discovery-heuristic-00.txt Thread-Index: Acwevpw8zf4ZcYbGSIma0tKrdgjVhgAQtsCQAAI/btAAKz+OoAAUxAKAAAxIx5D//yUfAP//KLvA Date: Wed, 1 Jun 2011 09:01:23 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962060B25@008-AM1MPN1-036.mgdnok.nokia.com> References: <916CE6CF87173740BC8A2CE44309696205EE34@008-AM1MPN1-036.mgdnok.nokia.com> <22F6318E46E26B498ABC828879B08D4F15E1D3@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> <916CE6CF87173740BC8A2CE44309696205F2D0@008-AM1MPN1-036.mgdnok.nokia.com> <22F6318E46E26B498ABC828879B08D4F15ECE0@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> <20110531201801.GA26780@shinkuro.com> <22F6318E46E26B498ABC828879B08D4F15F12F@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> <20110531220622.GF26780@shinkuro.com> In-Reply-To: <20110531220622.GF26780@shinkuro.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: 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: 01 Jun 2011 09:01:24.0671 (UTC) FILETIME=[7BF46CF0:01CC203A] X-Nokia-AV: Clean Subject: Re: [BEHAVE] Next for draft-ietf-behave-nat64-discovery-heuristic-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: Wed, 01 Jun 2011 09:01:31 -0000 Originally the idea was that the name is well-known for the entity that req= uires NAT64/NSP discovery. It could be e.g. an application or an OS. Hence = there would be no need to discover the name - and the name + public IPv4 ad= dress would be arranged by said application/OS vendor.. But that approach m= ight not be so nice for generic DNSSEC recursive resolvers to learn the pre= fix.. Teemu > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf > Of ext Andrew Sullivan > Sent: 01. kes=E4kuuta 2011 01:06 > To: behave@ietf.org > Subject: Re: [BEHAVE] Next for draft-ietf-behave-nat64-discovery-heuristi= c- > 00.txt >=20 > On Tue, May 31, 2011 at 09:36:35PM +0000, Christian Huitema wrote: > > > > I am clearly not looking at something configured via DHCP. There are > > plenty of configuration parameters that are not dependent on the local > > network. For example, my laptop is configured with the domain name of > > my mail server. That name will not change as the laptop moves from a > > coffee shop to the airport. Similarly, my SIP client is configured > > with the domain name of the STUN/TURN server that is uses for NAT > > traversal. The same SIP client could actually easily be configured > > with the name of the "NAT 64 discovery server." >=20 > You seem to be arguing, then, that instead of applications themselves hav= ing a > global well-known value that they know how to interpret (which is, from a= DNS > point of view, already worse than a single global one), we'll just have e= veryone > set up their own? >=20 >=20 > I guess this has the advantage that it's easier on the DNS (it's just one= more of > the usual lookups everyone is already doing), but it has the conspicuous > disadvantage that if you don't already have this configured, you need to = learn > how. I thought the point of this was supposed to be that it would work f= or the > most naive user? (I'm not trying to be argumentative. I'm just trying t= o > understand the use here, since I thought something more elegant than a we= ll- > known name was what we were going to use until I learned otherwise in > Prague.) >=20 > A >=20 > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From ajs@anvilwalrusden.com Wed Jun 1 06:11: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 03056E0823 for ; Wed, 1 Jun 2011 06:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 ruO06SQdmQXT for ; Wed, 1 Jun 2011 06:11:57 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 58646E080C for ; Wed, 1 Jun 2011 06:11:57 -0700 (PDT) Received: from shinkuro.com (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 813861ECB41C for ; Wed, 1 Jun 2011 13:11:55 +0000 (UTC) Date: Wed, 1 Jun 2011 09:11:54 -0400 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20110601131153.GJ26780@shinkuro.com> References: <916CE6CF87173740BC8A2CE44309696205EE34@008-AM1MPN1-036.mgdnok.nokia.com> <22F6318E46E26B498ABC828879B08D4F15E1D3@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> <916CE6CF87173740BC8A2CE44309696205F2D0@008-AM1MPN1-036.mgdnok.nokia.com> <22F6318E46E26B498ABC828879B08D4F15ECE0@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> <20110531201801.GA26780@shinkuro.com> <22F6318E46E26B498ABC828879B08D4F15F12F@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> <20110531220622.GF26780@shinkuro.com> <916CE6CF87173740BC8A2CE443096962060B25@008-AM1MPN1-036.mgdnok.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <916CE6CF87173740BC8A2CE443096962060B25@008-AM1MPN1-036.mgdnok.nokia.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [BEHAVE] Next for draft-ietf-behave-nat64-discovery-heuristic-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: Wed, 01 Jun 2011 13:11:58 -0000 On Wed, Jun 01, 2011 at 09:01:23AM +0000, teemu.savolainen@nokia.com wrote: > Originally the idea was that the name is well-known for the entity > that requires NAT64/NSP discovery. It could be e.g. an application > or an OS. If applications are going to do this independently, there is nothing at all for us to standardize. They should do what they want. It is only if there is an _inter_operability problem where we have something to say. What I heard in Prague was that some applications were already planning to do this, and so it seemed to me that, if we're going to get this kind of behaviour it would be better if everyone did it the same way. > application/OS vendor.. But that approach might not be so nice for > generic DNSSEC recursive resolvers to learn the prefix.. This is one reason why it would be better if everyone did it the same way: a DNS resolver that wants to provide DNSSEC or that wants to provide this information to the applications on the platform could learn the prefix quickly and easily. Otherwise, the DNS resolver library "vendor" will have to come up with its own heuristic. I appreciate the problem about the ranges suggested for the IP address to be returned. Perhaps that is resolvable another way: waste one real IPv4 address. A > > Teemu > > > -----Original Message----- > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf > > Of ext Andrew Sullivan > > Sent: 01. kesäkuuta 2011 01:06 > > To: behave@ietf.org > > Subject: Re: [BEHAVE] Next for draft-ietf-behave-nat64-discovery-heuristic- > > 00.txt > > > > On Tue, May 31, 2011 at 09:36:35PM +0000, Christian Huitema wrote: > > > > > > I am clearly not looking at something configured via DHCP. There are > > > plenty of configuration parameters that are not dependent on the local > > > network. For example, my laptop is configured with the domain name of > > > my mail server. That name will not change as the laptop moves from a > > > coffee shop to the airport. Similarly, my SIP client is configured > > > with the domain name of the STUN/TURN server that is uses for NAT > > > traversal. The same SIP client could actually easily be configured > > > with the name of the "NAT 64 discovery server." > > > > You seem to be arguing, then, that instead of applications themselves having a > > global well-known value that they know how to interpret (which is, from a DNS > > point of view, already worse than a single global one), we'll just have everyone > > set up their own? > > > > > > I guess this has the advantage that it's easier on the DNS (it's just one more of > > the usual lookups everyone is already doing), but it has the conspicuous > > disadvantage that if you don't already have this configured, you need to learn > > how. I thought the point of this was supposed to be that it would work for the > > most naive user? (I'm not trying to be argumentative. I'm just trying to > > understand the use here, since I thought something more elegant than a well- > > known name was what we were going to use until I learned otherwise in > > Prague.) > > > > A > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave -- Andrew Sullivan ajs@anvilwalrusden.com From teemu.savolainen@nokia.com Wed Jun 1 06:28:51 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 2A8C8E0801 for ; Wed, 1 Jun 2011 06:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.224 X-Spam-Level: X-Spam-Status: No, score=-3.224 tagged_above=-999 required=5 tests=[AWL=0.375, 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 qjMsZlzbe6Ve for ; Wed, 1 Jun 2011 06:28:50 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 78223E07FE for ; Wed, 1 Jun 2011 06:28:50 -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 p51DSjrA000481; Wed, 1 Jun 2011 16:28:47 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 1 Jun 2011 16:28:44 +0300 Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 1 Jun 2011 15:28:44 +0200 Received: from 008-AM1MPN1-036.mgdnok.nokia.com ([169.254.6.209]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0289.008; Wed, 1 Jun 2011 15:28:36 +0200 From: To: , Thread-Topic: [BEHAVE] Next for draft-ietf-behave-nat64-discovery-heuristic-00.txt Thread-Index: Acwevpw8zf4ZcYbGSIma0tKrdgjVhgAQtsCQAAI/btAAKz+OoAAUxAKAAAxIx5D//yUfAP//KLvAgAHURgD//9pScA== Date: Wed, 1 Jun 2011 13:28:35 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962060D53@008-AM1MPN1-036.mgdnok.nokia.com> References: <916CE6CF87173740BC8A2CE44309696205EE34@008-AM1MPN1-036.mgdnok.nokia.com> <22F6318E46E26B498ABC828879B08D4F15E1D3@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> <916CE6CF87173740BC8A2CE44309696205F2D0@008-AM1MPN1-036.mgdnok.nokia.com> <22F6318E46E26B498ABC828879B08D4F15ECE0@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> <20110531201801.GA26780@shinkuro.com> <22F6318E46E26B498ABC828879B08D4F15F12F@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> <20110531220622.GF26780@shinkuro.com> <916CE6CF87173740BC8A2CE443096962060B25@008-AM1MPN1-036.mgdnok.nokia.com> <20110601131153.GJ26780@shinkuro.com> In-Reply-To: <20110601131153.GJ26780@shinkuro.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.162.78.119] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 01 Jun 2011 13:28:44.0950 (UTC) FILETIME=[D4B4C360:01CC205F] X-Nokia-AV: Clean Subject: Re: [BEHAVE] Next for draft-ietf-behave-nat64-discovery-heuristic-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: Wed, 01 Jun 2011 13:28:51 -0000 SGksDQoNCkkgcHJlZmVyIHRoZSB3ZWxsLWtub3duIG5hbWUgYXBwcm9hY2ggaWYgd2UgaGF2ZSBy b3VnaCBjb25zZW5zdXMgZm9yIGl0Lg0KDQpXaGVyZSBjYW4gd2UgdGhlbiBnZXQgb25lIHB1Ymxp YyBJUHY0IGFkZHJlc3MsIGlmIElBTkEgaXMgb3V0IGFuZCBJRVRGIGhhcyBvbmx5ICJpbnZhbGlk IiBhZGRyZXNzZXM/DQoNCkRvbmF0aW9uIGZyb20gc29tZW9uZT8tKSANCg0KCVRlZW11DQoNCg0K DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGJlaGF2ZS1ib3VuY2VzQGll dGYub3JnIFttYWlsdG86YmVoYXZlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPiBPZiBl eHQgQW5kcmV3IFN1bGxpdmFuDQo+IFNlbnQ6IDAxLiBrZXPDpGt1dXRhIDIwMTEgMTY6MTINCj4g VG86IGJlaGF2ZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW0JFSEFWRV0gTmV4dCBmb3IgZHJh ZnQtaWV0Zi1iZWhhdmUtbmF0NjQtZGlzY292ZXJ5LWhldXJpc3RpYy0NCj4gMDAudHh0DQo+IA0K PiBPbiBXZWQsIEp1biAwMSwgMjAxMSBhdCAwOTowMToyM0FNICswMDAwLCB0ZWVtdS5zYXZvbGFp bmVuQG5va2lhLmNvbQ0KPiB3cm90ZToNCj4gDQo+ID4gT3JpZ2luYWxseSB0aGUgaWRlYSB3YXMg dGhhdCB0aGUgbmFtZSBpcyB3ZWxsLWtub3duIGZvciB0aGUgZW50aXR5DQo+ID4gdGhhdCByZXF1 aXJlcyBOQVQ2NC9OU1AgZGlzY292ZXJ5LiBJdCBjb3VsZCBiZSBlLmcuIGFuIGFwcGxpY2F0aW9u IG9yDQo+ID4gYW4gT1MuDQo+IA0KPiBJZiBhcHBsaWNhdGlvbnMgYXJlIGdvaW5nIHRvIGRvIHRo aXMgaW5kZXBlbmRlbnRseSwgdGhlcmUgaXMgbm90aGluZyBhdCBhbGwgZm9yIHVzDQo+IHRvIHN0 YW5kYXJkaXplLiAgVGhleSBzaG91bGQgZG8gd2hhdCB0aGV5IHdhbnQuICBJdCBpcyBvbmx5IGlm IHRoZXJlIGlzIGFuDQo+IF9pbnRlcl9vcGVyYWJpbGl0eSBwcm9ibGVtIHdoZXJlIHdlIGhhdmUg c29tZXRoaW5nIHRvIHNheS4gIFdoYXQgSSBoZWFyZCBpbg0KPiBQcmFndWUgd2FzIHRoYXQgc29t ZSBhcHBsaWNhdGlvbnMgd2VyZSBhbHJlYWR5IHBsYW5uaW5nIHRvIGRvIHRoaXMsIGFuZCBzbyBp dA0KPiBzZWVtZWQgdG8gbWUgdGhhdCwgaWYgd2UncmUgZ29pbmcgdG8gZ2V0IHRoaXMga2luZCBv ZiBiZWhhdmlvdXIgaXQgd291bGQgYmUNCj4gYmV0dGVyIGlmIGV2ZXJ5b25lIGRpZCBpdCB0aGUg c2FtZSB3YXkuDQo+IA0KPiA+IGFwcGxpY2F0aW9uL09TIHZlbmRvci4uIEJ1dCB0aGF0IGFwcHJv YWNoIG1pZ2h0IG5vdCBiZSBzbyBuaWNlIGZvcg0KPiA+IGdlbmVyaWMgRE5TU0VDIHJlY3Vyc2l2 ZSByZXNvbHZlcnMgdG8gbGVhcm4gdGhlIHByZWZpeC4uDQo+IA0KPiBUaGlzIGlzIG9uZSByZWFz b24gd2h5IGl0IHdvdWxkIGJlIGJldHRlciBpZiBldmVyeW9uZSBkaWQgaXQgdGhlIHNhbWUNCj4g d2F5OiBhIEROUyByZXNvbHZlciB0aGF0IHdhbnRzIHRvIHByb3ZpZGUgRE5TU0VDIG9yIHRoYXQg d2FudHMgdG8gcHJvdmlkZSB0aGlzDQo+IGluZm9ybWF0aW9uIHRvIHRoZSBhcHBsaWNhdGlvbnMg b24gdGhlIHBsYXRmb3JtIGNvdWxkIGxlYXJuIHRoZSBwcmVmaXggcXVpY2tseQ0KPiBhbmQgZWFz aWx5LiAgT3RoZXJ3aXNlLCB0aGUgRE5TIHJlc29sdmVyIGxpYnJhcnkgInZlbmRvciIgd2lsbCBo YXZlIHRvIGNvbWUgdXANCj4gd2l0aCBpdHMgb3duIGhldXJpc3RpYy4NCj4gDQo+IEkgYXBwcmVj aWF0ZSB0aGUgcHJvYmxlbSBhYm91dCB0aGUgcmFuZ2VzIHN1Z2dlc3RlZCBmb3IgdGhlIElQIGFk ZHJlc3MgdG8gYmUNCj4gcmV0dXJuZWQuICBQZXJoYXBzIHRoYXQgaXMgcmVzb2x2YWJsZSBhbm90 aGVyIHdheTogd2FzdGUgb25lIHJlYWwgSVB2NCBhZGRyZXNzLg0KPiANCj4gQQ0KPiANCj4gPg0K PiA+IAlUZWVtdQ0KPiA+DQo+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4g RnJvbTogYmVoYXZlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpiZWhhdmUtYm91bmNlc0BpZXRm Lm9yZ10gT24NCj4gPiA+IEJlaGFsZiBPZiBleHQgQW5kcmV3IFN1bGxpdmFuDQo+ID4gPiBTZW50 OiAwMS4ga2Vzw6RrdXV0YSAyMDExIDAxOjA2DQo+ID4gPiBUbzogYmVoYXZlQGlldGYub3JnDQo+ ID4gPiBTdWJqZWN0OiBSZTogW0JFSEFWRV0gTmV4dCBmb3INCj4gPiA+IGRyYWZ0LWlldGYtYmVo YXZlLW5hdDY0LWRpc2NvdmVyeS1oZXVyaXN0aWMtDQo+ID4gPiAwMC50eHQNCj4gPiA+DQo+ID4g PiBPbiBUdWUsIE1heSAzMSwgMjAxMSBhdCAwOTozNjozNVBNICswMDAwLCBDaHJpc3RpYW4gSHVp dGVtYSB3cm90ZToNCj4gPiA+ID4NCj4gPiA+ID4gSSBhbSBjbGVhcmx5IG5vdCBsb29raW5nIGF0 IHNvbWV0aGluZyBjb25maWd1cmVkIHZpYSBESENQLiBUaGVyZQ0KPiA+ID4gPiBhcmUgcGxlbnR5 IG9mIGNvbmZpZ3VyYXRpb24gcGFyYW1ldGVycyB0aGF0IGFyZSBub3QgZGVwZW5kZW50IG9uDQo+ ID4gPiA+IHRoZSBsb2NhbCBuZXR3b3JrLiBGb3IgZXhhbXBsZSwgbXkgbGFwdG9wIGlzIGNvbmZp Z3VyZWQgd2l0aCB0aGUNCj4gPiA+ID4gZG9tYWluIG5hbWUgb2YgbXkgbWFpbCBzZXJ2ZXIuIFRo YXQgbmFtZSB3aWxsIG5vdCBjaGFuZ2UgYXMgdGhlDQo+ID4gPiA+IGxhcHRvcCBtb3ZlcyBmcm9t IGEgY29mZmVlIHNob3AgdG8gdGhlIGFpcnBvcnQuIFNpbWlsYXJseSwgbXkgU0lQDQo+ID4gPiA+ IGNsaWVudCBpcyBjb25maWd1cmVkIHdpdGggdGhlIGRvbWFpbiBuYW1lIG9mIHRoZSBTVFVOL1RV Uk4gc2VydmVyDQo+ID4gPiA+IHRoYXQgaXMgdXNlcyBmb3IgTkFUIHRyYXZlcnNhbC4gVGhlIHNh bWUgU0lQIGNsaWVudCBjb3VsZCBhY3R1YWxseQ0KPiA+ID4gPiBlYXNpbHkgYmUgY29uZmlndXJl ZCB3aXRoIHRoZSBuYW1lIG9mIHRoZSAiTkFUIDY0IGRpc2NvdmVyeSBzZXJ2ZXIuIg0KPiA+ID4N Cj4gPiA+IFlvdSBzZWVtIHRvIGJlIGFyZ3VpbmcsIHRoZW4sIHRoYXQgaW5zdGVhZCBvZiBhcHBs aWNhdGlvbnMNCj4gPiA+IHRoZW1zZWx2ZXMgaGF2aW5nIGEgZ2xvYmFsIHdlbGwta25vd24gdmFs dWUgdGhhdCB0aGV5IGtub3cgaG93IHRvDQo+ID4gPiBpbnRlcnByZXQgKHdoaWNoIGlzLCBmcm9t IGEgRE5TIHBvaW50IG9mIHZpZXcsIGFscmVhZHkgd29yc2UgdGhhbiBhDQo+ID4gPiBzaW5nbGUg Z2xvYmFsIG9uZSksIHdlJ2xsIGp1c3QgaGF2ZSBldmVyeW9uZSBzZXQgdXAgdGhlaXIgb3duPw0K PiA+ID4NCj4gPiA+DQo+ID4gPiBJIGd1ZXNzIHRoaXMgaGFzIHRoZSBhZHZhbnRhZ2UgdGhhdCBp dCdzIGVhc2llciBvbiB0aGUgRE5TIChpdCdzDQo+ID4gPiBqdXN0IG9uZSBtb3JlIG9mIHRoZSB1 c3VhbCBsb29rdXBzIGV2ZXJ5b25lIGlzIGFscmVhZHkgZG9pbmcpLCBidXQNCj4gPiA+IGl0IGhh cyB0aGUgY29uc3BpY3VvdXMgZGlzYWR2YW50YWdlIHRoYXQgaWYgeW91IGRvbid0IGFscmVhZHkg aGF2ZQ0KPiA+ID4gdGhpcyBjb25maWd1cmVkLCB5b3UgbmVlZCB0byBsZWFybiBob3cuICBJIHRo b3VnaHQgdGhlIHBvaW50IG9mIHRoaXMNCj4gPiA+IHdhcyBzdXBwb3NlZCB0byBiZSB0aGF0IGl0 IHdvdWxkIHdvcmsgZm9yIHRoZSBtb3N0IG5haXZlIHVzZXI/ICAoSSdtDQo+ID4gPiBub3QgdHJ5 aW5nIHRvIGJlIGFyZ3VtZW50YXRpdmUuICBJJ20ganVzdCB0cnlpbmcgdG8gdW5kZXJzdGFuZCB0 aGUNCj4gPiA+IHVzZSBoZXJlLCBzaW5jZSBJIHRob3VnaHQgc29tZXRoaW5nIG1vcmUgZWxlZ2Fu dCB0aGFuIGEgd2VsbC0ga25vd24NCj4gPiA+IG5hbWUgd2FzIHdoYXQgd2Ugd2VyZSBnb2luZyB0 byB1c2UgdW50aWwgSSBsZWFybmVkIG90aGVyd2lzZSBpbg0KPiA+ID4gUHJhZ3VlLikNCj4gPiA+ DQo+ID4gPiBBDQo+ID4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+ID4gQmVoYXZlIG1haWxpbmcgbGlzdA0KPiA+IEJlaGF2ZUBpZXRmLm9y Zw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYmVoYXZlDQo+IA0K PiAtLQ0KPiBBbmRyZXcgU3VsbGl2YW4NCj4gYWpzQGFudmlsd2FscnVzZGVuLmNvbQ0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBCZWhhdmUgbWFp bGluZyBsaXN0DQo+IEJlaGF2ZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2JlaGF2ZQ0K From ietfdbh@comcast.net Fri Jun 3 05:06: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 995F4E0742 for ; Fri, 3 Jun 2011 05:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.621 X-Spam-Level: X-Spam-Status: No, score=-101.621 tagged_above=-999 required=5 tests=[AWL=-0.652, BAYES_00=-2.599, 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 hXTckHTbyV8k for ; Fri, 3 Jun 2011 05:06:35 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id 9D920E0741 for ; Fri, 3 Jun 2011 05:06:35 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta13.westchester.pa.mail.comcast.net with comcast id rQ5w1g0040mv7h05DQ6cof; Fri, 03 Jun 2011 12:06:36 +0000 Received: from davidPC ([67.189.235.106]) by omta11.westchester.pa.mail.comcast.net with comcast id rQ6a1g00P2JQnJT3XQ6a8G; Fri, 03 Jun 2011 12:06:35 +0000 From: "David Harrington" To: , "'Dan Wing'" Date: Fri, 3 Jun 2011 08:06:31 -0400 Message-ID: <04C1AFDBEA554F3FA5FDD978C1682D6E@davidPC> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.1.7600.16776 Thread-Index: AcweriFgX8TcPgo4RWWTGlEnMvid9QDMhohQ Cc: behave@ietf.org, behave-chairs@tools.ietf.org Subject: [BEHAVE] FW: Last Call: (An FTP ALG for IPv6-to-IPv4 translation) to Proposed Standard 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, 03 Jun 2011 12:06:36 -0000 Hi, Can you address these issues? Do you have any other comments you know of that need to be included in a new rev? As soon as you get a revised ID, and the shepherd gives me a go-ahead that we've caught all comments, I'll schedule the doc for an IESG telechat. David Harrington Director, IETF Transport Area ietfdbh@comcast.net (preferred for ietf) dbharrington@huaweisymantec.com +1 603 828 1401 (cell) -----Original Message----- From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of Pekka Savola Sent: Monday, May 30, 2011 5:10 AM To: ietf@ietf.org Cc: draft-ietf-behave-ftp64.all@tools.ietf.org; behave@ietf.org Subject: Re: [BEHAVE] Last Call: (An FTP ALG for IPv6-to-IPv4 translation) to Proposed Standard On Fri, 20 May 2011, The IESG wrote: > The IESG has received a request from the Behavior Engineering for > Hindrance Avoidance WG (behave) to consider the following document: > - 'An FTP ALG for IPv6-to-IPv4 translation' > as a Proposed Standard This is an ops-dir review of draft-ietf-behave-ftp64-10. I do not find major issues in the document. This is a somewhat complex document and I would have hoped that the spec could have been more straightforward and the result is some 50 MUSTs, SHOULDs and MAYs. But I suppose FTP legacy cases and implementations etc. make it a difficult protocol to support in the real life. substantial comments -------------------- The document does not mention or discuss LPRT and LPSV. Is that intentional? The IANA registry says these are now obsolete, but RFC1639 is still experimental and no document has (formally) obsoleted these. S 5: Telnet option negotiation attempts by either the client or the server, except for those allowed by [RFC1123], MUST be rejected by the FTP ALG without relaying those attempts. This avoids the situation where the client and the server negotiate Telnet options that are unimplemented by the FTP ALG. ... what does "rejected" mean exactly? Does the ALG send back to the negotiation attempter some error code? Does it abort the connection? ignore these options? strip them out when connecting to the other end? 8. Default port 20 translation If the client does not issue an EPSV/PASV or EPRT/PORT command prior to initiating a file transfer, it is invoking the default active FTP behavior where the server sets up a TCP session towards the client. In this situation, the source port number is the default FTP data port (port 20) and the destination port is the port the client uses as the source port for the control channel session. .. is it? I thought the source port used by the server is orthogonal to whether pasv/port is issued. AFAIK, multiple FTP server implementations never use port 20. But I have not recently tested this myself. The ALG MUST enable or disable EPSV to PASV translation as requested. If EPRT to PORT translation is supported, ALGS ENABLE64 SHOULD enable it and ALGS DISABLE64 SHOULD disable it along with enabling or disabling EPSV to PASV translation, respectively. If EPRT to PORT translation is not supported, ALGS ENABLE64 only enables EPSV to PASV translation. .. what does this SHOULD..along with.. mean? I read it so that it's OK that for "ALGS DISABLE64" EPSV->PASV is disabled but EPRT->PORT is not disabled? A different way to read it would be that both EPSV->PASV and EPRT->PORT are SHOULDs. editorial: ---------- A survey done in April of 2009 of 25 randomly picked and/or well- known FTP sites reachable over IPv4 showed that only 12 of them supported EPSV over IPv4. .. fwiw, Dan Wing redid this test on 18 May 2011, reporting on behave list. the results didn't differ much (I didn't look at the numbers), but if you want to update this, now would be the chance. If such a multi-purpose ALG forbids the use of the AUTH command for policy reasons, the side effect of making the ALG stop performing the translations described here, as well as other possible interventions related to IPv6-to-IPv4 translation, MUST be retained even if the ALG responds to the AUTH command with an error and does not propagate the command to the server. .. I had a hard time following what this one sentence includign a MUST actually requires. Maybe break down to more easily digestible sentences? [Bernstein] Bernstein, D., "PASV security and PORT security", 2000, . .. this reference is not cited in the doc, add or remove? _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From iljitsch@muada.com Mon Jun 6 09:57: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 506A211E81A5 for ; Mon, 6 Jun 2011 09:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 rsCZMnV5SWwV for ; Mon, 6 Jun 2011 09:57:57 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id 2777F11E8179 for ; Mon, 6 Jun 2011 09:57:56 -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 p56GwcXP003044 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 6 Jun 2011 18:58:39 +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: <04C1AFDBEA554F3FA5FDD978C1682D6E@davidPC> Date: Mon, 6 Jun 2011 18:57:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0A90C41B-67D1-48F4-801F-8A08EA103335@muada.com> References: <04C1AFDBEA554F3FA5FDD978C1682D6E@davidPC> To: David Harrington X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-behave-ftp64.all@tools.ietf.org, behave@ietf.org, behave-chairs@tools.ietf.org, 'Dan Wing' Subject: Re: [BEHAVE] FW: Last Call: (An FTP ALG for IPv6-to-IPv4 translation) to Proposed Standard 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, 06 Jun 2011 16:57:58 -0000 On 3 jun 2011, at 14:06, David Harrington wrote: > Can you address these issues? > Do you have any other comments you know of that need to be included in > a new rev? There have been three reviews, I'll include the comments and/or talk to = the commenters and do a new version at the end of the week. Iljitsch From mohamed.boucadair@orange-ftgroup.com Fri Jun 10 04:53: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 3F5BD11E8083; Fri, 10 Jun 2011 04:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.247 X-Spam-Level: X-Spam-Status: No, score=-2.247 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=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 UXXnCCAa-7bz; Fri, 10 Jun 2011 04:53:22 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id 1580911E807E; Fri, 10 Jun 2011 04:53:22 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id F2BB12AC415; Fri, 10 Jun 2011 13:53:20 +0200 (CEST) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id CE042C805C; Fri, 10 Jun 2011 13:53:20 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Fri, 10 Jun 2011 13:53:20 +0200 From: To: "behave@ietf.org" , "int-area@ietf.org" , 'Behave Chairs' , "intarea-chairs@tools.ietf.org" Date: Fri, 10 Jun 2011 13:53:18 +0200 Thread-Topic: Analysis of Solution Candidates to Reveal a Host Identifier in Shared Address Deployments I-D Thread-Index: AcwnZP1jDfelOgRuT1G1WudO8+/Z0Q== Message-ID: <94C682931C08B048B7A8645303FDC9F33E5016263D@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F33E5016263DPUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.6.10.111214 Cc: 'Tom Taylor' , 'Bob Briscoe' , 'Marc Blanchet' , "draft-boucadair-intarea-nat-reveal-analysis@tools.ietf.org" , 'Dan Wing' , 'ZhangDong' , "fine_sz@huawei.com" , Peter McCann , Tina Tsou Subject: [BEHAVE] Analysis of Solution Candidates to Reveal a Host Identifier in Shared Address Deployments I-D 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, 10 Jun 2011 11:53:23 -0000 --_000_94C682931C08B048B7A8645303FDC9F33E5016263DPUEXCB1Bnante_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, A new version of the draft taking into account the comments received in Pra= gue (INTAREA and BEHAVE meetings) has been submitted: http://www.ietf.org/internet-drafts/draft-boucadair-intarea-nat-reveal-anal= ysis-02.txt In particular, a new sub-section has been introduced to clarify the confusi= ons related to privacy concerns. As stated in the document, the purpose of this document is not to advocate = for the practice to inject a HOST_ID but to analyse to what extent these so= lutions mitigate some of the issues documented in http://tools.ietf.org/htm= l/draft-ietf-intarea-shared-addressing-issues-05 and to identify the side e= ffects and the viability of the proposed solutions. The document focuses on IPv4 address sharing (e.g., NAT44, DS-Lite, NAT64) = but some issues may be valid for IPv6 too (e.g., hosts sharing the same /64= ). We, authors of this document, would like to see this work progress within i= ntarea or behave since these two WG seems to be concerned with these issues= . Guidelines from BEHAVE and INTAREA chairs for the appropriate working to = host this work are more than welcome. Questions, comments, suggestions are welcome. Cheers, Med --_000_94C682931C08B048B7A8645303FDC9F33E5016263DPUEXCB1Bnante_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
D= ear=20 all,
 
A= new=20 version of the draft taking into account the comments received in Prague=20 (INTAREA and BEHAVE meetings) has been submitted:
<= A=20 href=3D"http://www.ietf.org/internet-drafts/draft-boucadair-intarea-nat-rev= eal-analysis-02.txt">http://www.ietf.org/internet-drafts/draft-boucadair-intarea-nat-r= eveal-analysis-02.txt
 
I= n=20 particular, a new sub-section has been introduced to clarify the confusions= =20 related to privacy concerns.
 
A= s stated in=20 the document, the purpose of this document is not to advocate for the pract= ice=20 to inject a HOST_ID but to analyse to what extent these solutions mitigate = some=20 of the issues documented in http://tools.ietf.org/html/draft-ietf-intarea-shared-addressing-iss= ues-05 and=20 to identify the side effects and the viability of the proposed=20 solutions.
 
T= he document=20 focuses on IPv4 address sharing (e.g., NAT44, DS-Lite, NAT64) but some= =20 issues may be valid for IPv6 too (e.g., hosts sharing the same=20 /64). 
 
W= e, authors=20 of this document, would like to see this work progress within intarea or be= have=20 since these two WG seems to be concerned with these issues. Guidelines from= =20 BEHAVE and INTAREA chairs for the appropriate working to host this wor= k are=20 more than welcome.
 
Q= uestions,=20 comments, suggestions are welcome.
 
Cheers,
Med
--_000_94C682931C08B048B7A8645303FDC9F33E5016263DPUEXCB1Bnante_-- From dwing@cisco.com Fri Jun 10 18:21: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 3349F11E80B7 for ; Fri, 10 Jun 2011 18:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.949 X-Spam-Level: X-Spam-Status: No, score=-109.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWk8Bj4-IJYL for ; Fri, 10 Jun 2011 18:21:37 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id BBDD39E802C for ; Fri, 10 Jun 2011 18:21:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2038; q=dns/txt; s=iport; t=1307755296; x=1308964896; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=n6Vb/CUmUCFU+OtjDcI/Ac+tTFET8/0A3aKwdxPSiuM=; b=jjeFhCU4bnIVK3vUXypkZFiunNunmaJCKiIc/NZFTSYoFZrAgvkEOBLI Zcq6Rp/+pr6uqjP1au9TvnGYCBHRnZcBbB+fDrPoMZdg64nwmnDELbXXV DQ1bUjMnfPlrBOwb8JRO9G5kxmNWDocoy4xVhcY+jEkvea8Dj1N01CrwP c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAGLC8k2rRDoG/2dsb2JhbABSmTuNEnemJZ4UhiQEhwuaHg X-IronPort-AV: E=Sophos;i="4.65,350,1304294400"; d="scan'208";a="374599661" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 11 Jun 2011 01:21:36 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5B1LawE021733; Sat, 11 Jun 2011 01:21:36 GMT From: "Dan Wing" To: "Behave WG" Date: Fri, 10 Jun 2011 18:21:36 -0700 Message-ID: <04bd01cc27d5$e87375e0$b95a61a0$@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: Acwn1eguJRRv7kJmQ+Kd8tITmtQ4Rw== Content-Language: en-us Cc: behave-chairs@tools.ietf.org, 'Dave Thaler' Subject: [BEHAVE] BEHAVE presentations at IETF81 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 01:21:38 -0000 Hi. For IETF81, we need to have draft agendas to our area director to get agenda time. ********************************************************** ** If you are planning to present a non-working group ** ** document during the BEHAVE session at IETF81, send ** ** email to behave-chairs@tools.ietf.org by ** ** Wednesday, June 15. ** ********************************************************** >From our working group active documents list at http://tools.ietf.org/wg/behave, I expect we would have an agenda covering these items: * draft-ietf-behave-64-analysis, no presentation (was WGLC'd) * draft-ietf-behave-lsn-requirements, 20 minutes * draft-ietf-behave-nat64-discovery-heuristic, 20 minutes * draft-ietf-behave-nat64-learn-analysis, no presentation * draft-ietf-behave-sctpnat, no presentation * draft-ietf-behave-sctpnat, no presentation (was WGLC'd) of the "Related Active Documents (not working group documents)", here are my thoughts: * draft-boucadair-behave-bittorrent-address-sharing -- I believe this was going to be published AD-sponsored, unless there is interest in the working group on this document? If folks want to look at it, and decide if they could provide peer review, we might consider adopting this as a WG document. Please let me know. * draft-sivakumar-behave-nat-logging was requested to become a WG document. There was some feedback which I believe has not yet been integrated into the document. After that feedback is integrated, a presentation might be a good idea to determine if there is interest in adopting this as a WG document. * The various multicast documents with -behave- in their names should wait for the outcome of the multicast BoF, to see if there is interest in moving forward with multicast translation. If there are other things to discuss, send the chairs email. Right now, it appears we might only need 1.0 or 1.5 hours of meeting time. -d From teemu.savolainen@nokia.com Wed Jun 15 03:32: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 A734621F8516 for ; Wed, 15 Jun 2011 03:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 VhkL45Rv7xYf for ; Wed, 15 Jun 2011 03:32:49 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id CCCCB21F8515 for ; Wed, 15 Jun 2011 03:32:49 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p5FAVYMB002514; Wed, 15 Jun 2011 13:32:36 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 15 Jun 2011 13:32:05 +0300 Received: from 008-AM1MMR1-002.mgdnok.nokia.com (65.54.30.57) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 15 Jun 2011 12:32:05 +0200 Received: from 008-AM1MPN1-031.mgdnok.nokia.com ([169.254.1.208]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0289.008; Wed, 15 Jun 2011 12:32:04 +0200 From: To: , Thread-Topic: [BEHAVE] Next for draft-ietf-behave-nat64-discovery-heuristic-00.txt Thread-Index: Acwevpw8zf4ZcYbGSIma0tKrdgjVhgAQtsCQAAI/btAAKz+OoAAUxAKAAAxIx5D//yUfAP//KLvAgAHURgD//9pScP/p5U6g Date: Wed, 15 Jun 2011 10:32:04 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962075344@008-AM1MPN1-031.mgdnok.nokia.com> References: <916CE6CF87173740BC8A2CE44309696205EE34@008-AM1MPN1-036.mgdnok.nokia.com> <22F6318E46E26B498ABC828879B08D4F15E1D3@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> <916CE6CF87173740BC8A2CE44309696205F2D0@008-AM1MPN1-036.mgdnok.nokia.com> <22F6318E46E26B498ABC828879B08D4F15ECE0@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> <20110531201801.GA26780@shinkuro.com> <22F6318E46E26B498ABC828879B08D4F15F12F@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> <20110531220622.GF26780@shinkuro.com> <916CE6CF87173740BC8A2CE443096962060B25@008-AM1MPN1-036.mgdnok.nokia.com> <20110601131153.GJ26780@shinkuro.com> <916CE6CF87173740BC8A2CE443096962060D53@008-AM1MPN1-036.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE443096962060D53@008-AM1MPN1-036.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.162.78.119] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 15 Jun 2011 10:32:05.0690 (UTC) FILETIME=[78D689A0:01CC2B47] X-Nokia-AV: Clean Subject: Re: [BEHAVE] Next for draft-ietf-behave-nat64-discovery-heuristic-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: Wed, 15 Jun 2011 10:32:50 -0000 SGksDQoNCk9uZSB3YXkgdG8gYXZvaWQgZGVmaW5pbmcgc3RhdGljIHB1YmxpYyBJUHY0IGFkZHJl c3MgaGVyZSBpcyB0byBqdXN0IGhhdmUgd2VsbC1rbm93biBuYW1lLCBhbmQgdGhlbiBtYWtlIHRo ZSBjbGllbnQgdG8gZGlzY292ZXIgdGhlIElQdjQgYWRkcmVzcyBpbiB1c2UgYnkgZG9pbmcgQSBx dWVyeSBpbiBwYXJhbGxlbCB0byBBQUFBLiBXb3VsZCB0aGF0IGJlIGZpbmUgKGV4Y2VwdCBkb3Vi bGUgdGhlIG51bWJlciBvZiBxdWVyaWVzKT8NCg0KQmVzdCByZWdhcmRzLA0KDQoJVGVlbXUNCg0K PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBiZWhhdmUtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOmJlaGF2ZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4gT2YgZXh0 IHRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tDQo+IFNlbnQ6IDAxLiBrZXPDpGt1dXRhIDIwMTEg MTY6MjkNCj4gVG86IGFqc0BhbnZpbHdhbHJ1c2Rlbi5jb207IGJlaGF2ZUBpZXRmLm9yZw0KPiBT dWJqZWN0OiBSZTogW0JFSEFWRV0gTmV4dCBmb3IgZHJhZnQtaWV0Zi1iZWhhdmUtbmF0NjQtZGlz Y292ZXJ5LWhldXJpc3RpYy0NCj4gMDAudHh0DQo+IA0KPiBIaSwNCj4gDQo+IEkgcHJlZmVyIHRo ZSB3ZWxsLWtub3duIG5hbWUgYXBwcm9hY2ggaWYgd2UgaGF2ZSByb3VnaCBjb25zZW5zdXMgZm9y IGl0Lg0KPiANCj4gV2hlcmUgY2FuIHdlIHRoZW4gZ2V0IG9uZSBwdWJsaWMgSVB2NCBhZGRyZXNz LCBpZiBJQU5BIGlzIG91dCBhbmQgSUVURiBoYXMgb25seQ0KPiAiaW52YWxpZCIgYWRkcmVzc2Vz Pw0KPiANCj4gRG9uYXRpb24gZnJvbSBzb21lb25lPy0pDQo+IA0KPiAJVGVlbXUNCj4gDQo+IA0K PiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IGJlaGF2ZS1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86YmVoYXZlLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+ID4gQmVo YWxmIE9mIGV4dCBBbmRyZXcgU3VsbGl2YW4NCj4gPiBTZW50OiAwMS4ga2Vzw6RrdXV0YSAyMDEx IDE2OjEyDQo+ID4gVG86IGJlaGF2ZUBpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJlOiBbQkVIQVZF XSBOZXh0IGZvcg0KPiA+IGRyYWZ0LWlldGYtYmVoYXZlLW5hdDY0LWRpc2NvdmVyeS1oZXVyaXN0 aWMtDQo+ID4gMDAudHh0DQo+ID4NCj4gPiBPbiBXZWQsIEp1biAwMSwgMjAxMSBhdCAwOTowMToy M0FNICswMDAwLCB0ZWVtdS5zYXZvbGFpbmVuQG5va2lhLmNvbQ0KPiA+IHdyb3RlOg0KPiA+DQo+ ID4gPiBPcmlnaW5hbGx5IHRoZSBpZGVhIHdhcyB0aGF0IHRoZSBuYW1lIGlzIHdlbGwta25vd24g Zm9yIHRoZSBlbnRpdHkNCj4gPiA+IHRoYXQgcmVxdWlyZXMgTkFUNjQvTlNQIGRpc2NvdmVyeS4g SXQgY291bGQgYmUgZS5nLiBhbiBhcHBsaWNhdGlvbg0KPiA+ID4gb3IgYW4gT1MuDQo+ID4NCj4g PiBJZiBhcHBsaWNhdGlvbnMgYXJlIGdvaW5nIHRvIGRvIHRoaXMgaW5kZXBlbmRlbnRseSwgdGhl cmUgaXMgbm90aGluZw0KPiA+IGF0IGFsbCBmb3IgdXMgdG8gc3RhbmRhcmRpemUuICBUaGV5IHNo b3VsZCBkbyB3aGF0IHRoZXkgd2FudC4gIEl0IGlzDQo+ID4gb25seSBpZiB0aGVyZSBpcyBhbiBf aW50ZXJfb3BlcmFiaWxpdHkgcHJvYmxlbSB3aGVyZSB3ZSBoYXZlIHNvbWV0aGluZw0KPiA+IHRv IHNheS4gIFdoYXQgSSBoZWFyZCBpbiBQcmFndWUgd2FzIHRoYXQgc29tZSBhcHBsaWNhdGlvbnMg d2VyZQ0KPiA+IGFscmVhZHkgcGxhbm5pbmcgdG8gZG8gdGhpcywgYW5kIHNvIGl0IHNlZW1lZCB0 byBtZSB0aGF0LCBpZiB3ZSdyZQ0KPiA+IGdvaW5nIHRvIGdldCB0aGlzIGtpbmQgb2YgYmVoYXZp b3VyIGl0IHdvdWxkIGJlIGJldHRlciBpZiBldmVyeW9uZSBkaWQgaXQgdGhlDQo+IHNhbWUgd2F5 Lg0KPiA+DQo+ID4gPiBhcHBsaWNhdGlvbi9PUyB2ZW5kb3IuLiBCdXQgdGhhdCBhcHByb2FjaCBt aWdodCBub3QgYmUgc28gbmljZSBmb3INCj4gPiA+IGdlbmVyaWMgRE5TU0VDIHJlY3Vyc2l2ZSBy ZXNvbHZlcnMgdG8gbGVhcm4gdGhlIHByZWZpeC4uDQo+ID4NCj4gPiBUaGlzIGlzIG9uZSByZWFz b24gd2h5IGl0IHdvdWxkIGJlIGJldHRlciBpZiBldmVyeW9uZSBkaWQgaXQgdGhlIHNhbWUNCj4g PiB3YXk6IGEgRE5TIHJlc29sdmVyIHRoYXQgd2FudHMgdG8gcHJvdmlkZSBETlNTRUMgb3IgdGhh dCB3YW50cyB0bw0KPiA+IHByb3ZpZGUgdGhpcyBpbmZvcm1hdGlvbiB0byB0aGUgYXBwbGljYXRp b25zIG9uIHRoZSBwbGF0Zm9ybSBjb3VsZA0KPiA+IGxlYXJuIHRoZSBwcmVmaXggcXVpY2tseSBh bmQgZWFzaWx5LiAgT3RoZXJ3aXNlLCB0aGUgRE5TIHJlc29sdmVyDQo+ID4gbGlicmFyeSAidmVu ZG9yIiB3aWxsIGhhdmUgdG8gY29tZSB1cCB3aXRoIGl0cyBvd24gaGV1cmlzdGljLg0KPiA+DQo+ ID4gSSBhcHByZWNpYXRlIHRoZSBwcm9ibGVtIGFib3V0IHRoZSByYW5nZXMgc3VnZ2VzdGVkIGZv ciB0aGUgSVAgYWRkcmVzcw0KPiA+IHRvIGJlIHJldHVybmVkLiAgUGVyaGFwcyB0aGF0IGlzIHJl c29sdmFibGUgYW5vdGhlciB3YXk6IHdhc3RlIG9uZSByZWFsIElQdjQNCj4gYWRkcmVzcy4NCj4g Pg0KPiA+IEENCj4gPg0KPiA+ID4NCj4gPiA+IAlUZWVtdQ0KPiA+ID4NCj4gPiA+ID4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gRnJvbTogYmVoYXZlLWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzpiZWhhdmUtYm91bmNlc0BpZXRmLm9yZ10gT24NCj4gPiA+ID4gQmVoYWxmIE9m IGV4dCBBbmRyZXcgU3VsbGl2YW4NCj4gPiA+ID4gU2VudDogMDEuIGtlc8Oka3V1dGEgMjAxMSAw MTowNg0KPiA+ID4gPiBUbzogYmVoYXZlQGlldGYub3JnDQo+ID4gPiA+IFN1YmplY3Q6IFJlOiBb QkVIQVZFXSBOZXh0IGZvcg0KPiA+ID4gPiBkcmFmdC1pZXRmLWJlaGF2ZS1uYXQ2NC1kaXNjb3Zl cnktaGV1cmlzdGljLQ0KPiA+ID4gPiAwMC50eHQNCj4gPiA+ID4NCj4gPiA+ID4gT24gVHVlLCBN YXkgMzEsIDIwMTEgYXQgMDk6MzY6MzVQTSArMDAwMCwgQ2hyaXN0aWFuIEh1aXRlbWEgd3JvdGU6 DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBJIGFtIGNsZWFybHkgbm90IGxvb2tpbmcgYXQgc29tZXRo aW5nIGNvbmZpZ3VyZWQgdmlhIERIQ1AuIFRoZXJlDQo+ID4gPiA+ID4gYXJlIHBsZW50eSBvZiBj b25maWd1cmF0aW9uIHBhcmFtZXRlcnMgdGhhdCBhcmUgbm90IGRlcGVuZGVudCBvbg0KPiA+ID4g PiA+IHRoZSBsb2NhbCBuZXR3b3JrLiBGb3IgZXhhbXBsZSwgbXkgbGFwdG9wIGlzIGNvbmZpZ3Vy ZWQgd2l0aCB0aGUNCj4gPiA+ID4gPiBkb21haW4gbmFtZSBvZiBteSBtYWlsIHNlcnZlci4gVGhh dCBuYW1lIHdpbGwgbm90IGNoYW5nZSBhcyB0aGUNCj4gPiA+ID4gPiBsYXB0b3AgbW92ZXMgZnJv bSBhIGNvZmZlZSBzaG9wIHRvIHRoZSBhaXJwb3J0LiBTaW1pbGFybHksIG15DQo+ID4gPiA+ID4g U0lQIGNsaWVudCBpcyBjb25maWd1cmVkIHdpdGggdGhlIGRvbWFpbiBuYW1lIG9mIHRoZSBTVFVO L1RVUk4NCj4gPiA+ID4gPiBzZXJ2ZXIgdGhhdCBpcyB1c2VzIGZvciBOQVQgdHJhdmVyc2FsLiBU aGUgc2FtZSBTSVAgY2xpZW50IGNvdWxkDQo+ID4gPiA+ID4gYWN0dWFsbHkgZWFzaWx5IGJlIGNv bmZpZ3VyZWQgd2l0aCB0aGUgbmFtZSBvZiB0aGUgIk5BVCA2NCBkaXNjb3ZlcnkNCj4gc2VydmVy LiINCj4gPiA+ID4NCj4gPiA+ID4gWW91IHNlZW0gdG8gYmUgYXJndWluZywgdGhlbiwgdGhhdCBp bnN0ZWFkIG9mIGFwcGxpY2F0aW9ucw0KPiA+ID4gPiB0aGVtc2VsdmVzIGhhdmluZyBhIGdsb2Jh bCB3ZWxsLWtub3duIHZhbHVlIHRoYXQgdGhleSBrbm93IGhvdyB0bw0KPiA+ID4gPiBpbnRlcnBy ZXQgKHdoaWNoIGlzLCBmcm9tIGEgRE5TIHBvaW50IG9mIHZpZXcsIGFscmVhZHkgd29yc2UgdGhh bg0KPiA+ID4gPiBhIHNpbmdsZSBnbG9iYWwgb25lKSwgd2UnbGwganVzdCBoYXZlIGV2ZXJ5b25l IHNldCB1cCB0aGVpciBvd24/DQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+IEkgZ3Vlc3MgdGhp cyBoYXMgdGhlIGFkdmFudGFnZSB0aGF0IGl0J3MgZWFzaWVyIG9uIHRoZSBETlMgKGl0J3MNCj4g PiA+ID4ganVzdCBvbmUgbW9yZSBvZiB0aGUgdXN1YWwgbG9va3VwcyBldmVyeW9uZSBpcyBhbHJl YWR5IGRvaW5nKSwgYnV0DQo+ID4gPiA+IGl0IGhhcyB0aGUgY29uc3BpY3VvdXMgZGlzYWR2YW50 YWdlIHRoYXQgaWYgeW91IGRvbid0IGFscmVhZHkgaGF2ZQ0KPiA+ID4gPiB0aGlzIGNvbmZpZ3Vy ZWQsIHlvdSBuZWVkIHRvIGxlYXJuIGhvdy4gIEkgdGhvdWdodCB0aGUgcG9pbnQgb2YNCj4gPiA+ ID4gdGhpcyB3YXMgc3VwcG9zZWQgdG8gYmUgdGhhdCBpdCB3b3VsZCB3b3JrIGZvciB0aGUgbW9z dCBuYWl2ZQ0KPiA+ID4gPiB1c2VyPyAgKEknbSBub3QgdHJ5aW5nIHRvIGJlIGFyZ3VtZW50YXRp dmUuICBJJ20ganVzdCB0cnlpbmcgdG8NCj4gPiA+ID4gdW5kZXJzdGFuZCB0aGUgdXNlIGhlcmUs IHNpbmNlIEkgdGhvdWdodCBzb21ldGhpbmcgbW9yZSBlbGVnYW50DQo+ID4gPiA+IHRoYW4gYSB3 ZWxsLSBrbm93biBuYW1lIHdhcyB3aGF0IHdlIHdlcmUgZ29pbmcgdG8gdXNlIHVudGlsIEkNCj4g PiA+ID4gbGVhcm5lZCBvdGhlcndpc2UgaW4NCj4gPiA+ID4gUHJhZ3VlLikNCj4gPiA+ID4NCj4g PiA+ID4gQQ0KPiA+ID4gPg0KPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gPiA+IEJlaGF2ZSBtYWlsaW5nIGxpc3QNCj4gPiA+IEJlaGF2ZUBp ZXRmLm9yZw0KPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9iZWhh dmUNCj4gPg0KPiA+IC0tDQo+ID4gQW5kcmV3IFN1bGxpdmFuDQo+ID4gYWpzQGFudmlsd2FscnVz ZGVuLmNvbQ0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ID4gQmVoYXZlIG1haWxpbmcgbGlzdA0KPiA+IEJlaGF2ZUBpZXRmLm9yZw0KPiA+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYmVoYXZlDQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEJlaGF2ZSBtYWlsaW5nIGxp c3QNCj4gQmVoYXZlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vYmVoYXZlDQo= From linfeng.john.zheng@gmail.com Sat Jun 18 15:28:49 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 8D70011E80ED for ; Sat, 18 Jun 2011 15:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8hDisCaIXcK for ; Sat, 18 Jun 2011 15:28:48 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id C3A0511E80BC for ; Sat, 18 Jun 2011 15:28:48 -0700 (PDT) Received: by yxt33 with SMTP id 33so2900420yxt.31 for ; Sat, 18 Jun 2011 15:28:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=pEQMRmUOYYzNzYCIn0n4gNWvh7rnF5EAv+LDI2BmjS4=; b=jS7t0jPmc7VQwN8kwcdTWcjH+OJdM7VbsslSocp7/ZPtDpYaYrC6bmkmNYSTl4b/hp CtrExP5gOHW4ET8waNeuitX/zOfAzGM0RSnj2TJ14qcT79IApTV1IBERkZutuFMIDH2J 3I5sC/LAbF7mZIpeWw69B3b9/nbGdQIaaLWmA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=fa4yfLWxNTXFFc37/Q50cn6Y3T5rX89vFWs87LCghzcrxVCIuEPGatUB5Cle/YcZIP 0AJLz+psEcW+bEqHrhq9/gm/0aURPjEk7IEM/oWPdFUSRlgymj9ebXNCpCtLRYLcBmBJ tOiT0PjDyH//CmXpKN92BbEf7l/FA0U2YeDlk= MIME-Version: 1.0 Received: by 10.150.31.20 with SMTP id e20mr3772984ybe.62.1308436125719; Sat, 18 Jun 2011 15:28:45 -0700 (PDT) Received: by 10.151.78.6 with HTTP; Sat, 18 Jun 2011 15:28:45 -0700 (PDT) Date: Sun, 19 Jun 2011 06:28:45 +0800 Message-ID: From: Linfeng Zheng To: behave@ietf.org Content-Type: multipart/alternative; boundary=000e0cd358967c1d8904a6040648 Subject: [BEHAVE] Head up, song for IPv6. X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2011 22:28:49 -0000 --000e0cd358967c1d8904a6040648 Content-Type: text/plain; charset=ISO-8859-1 http://www.youtube.com/watch?v=_y36fG2Oba0 Cheers, John, CCIE#8670 Tel: 86-25-8577-1689 --000e0cd358967c1d8904a6040648 Content-Type: text/html; charset=ISO-8859-1
Cheers,

John, CCIE#8670
Tel: 86-25-8577-1689

--000e0cd358967c1d8904a6040648-- From internet-drafts@ietf.org Mon Jun 20 06:40:12 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 C9EF711E816C; Mon, 20 Jun 2011 06:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 r0cOCmom0i7G; Mon, 20 Jun 2011 06:40:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 627AC11E8125; Mon, 20 Jun 2011 06:40:12 -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: <20110620134012.14538.48129.idtracker@ietfa.amsl.com> Date: Mon, 20 Jun 2011 06:40:12 -0700 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-01.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, 20 Jun 2011 13:40:12 -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-01.txt Pages : 8 Date : 2011-06-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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-nat64-discovery-heuri= stic-01.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-01.txt From teemu.savolainen@nokia.com Mon Jun 20 11:53:52 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 6EE3511E81B4 for ; Mon, 20 Jun 2011 11:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.199 X-Spam-Level: X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[AWL=0.400, 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 X9t8+r0-3kUS for ; Mon, 20 Jun 2011 11:53:51 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id ADEC211E8161 for ; Mon, 20 Jun 2011 11:53:51 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p5KIrnNT024733 for ; Mon, 20 Jun 2011 21:53:50 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Jun 2011 21:53:44 +0300 Received: from 008-AM1MMR1-002.mgdnok.nokia.com (65.54.30.57) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 20 Jun 2011 20:53:44 +0200 Received: from 008-AM1MPN1-031.mgdnok.nokia.com ([169.254.1.208]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0289.008; Mon, 20 Jun 2011 20:53:43 +0200 From: To: Thread-Topic: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-01.txt Thread-Index: AQHML0+e/OXP37xTBk6Ait87ojx06pTGl0mw Date: Mon, 20 Jun 2011 18:53:43 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962077BD4@008-AM1MPN1-031.mgdnok.nokia.com> References: <20110620134012.14538.48129.idtracker@ietfa.amsl.com> In-Reply-To: <20110620134012.14538.48129.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.162.62.175] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 20 Jun 2011 18:53:44.0626 (UTC) FILETIME=[61447120:01CC2F7B] X-Nokia-AV: Clean Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-01.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, 20 Jun 2011 18:53:52 -0000 Hi all, Here's updated version to stir up some discussion. Now included e.g. exit s= trategy =3D queries for well-known name, A and AAAA records, resulting in N= XDOMAIN result once tool is disabled. Host may check with A record query if= the well-known name is out-of-use. What would be good TTL for well-known name? Week, month, year? And I still wonder for this global solution, where it is possible to obtain= a name and a global IPv4 address? Best regards, Teemu > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf > Of ext internet-drafts@ietf.org > Sent: 20. kes=E4kuuta 2011 16:40 > To: i-d-announce@ietf.org > Cc: behave@ietf.org > Subject: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic= -01.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 using a W= ell- > Known Name > Author(s) : Teemu Savolainen > Jouni Korhonen > Filename : draft-ietf-behave-nat64-discovery-heuristic-01.txt > Pages : 8 > Date : 2011-06-20 >=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- > 01.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- > 01.txt > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From simon.perreault@viagenie.ca Tue Jun 21 12:41: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 711801F0C67 for ; Tue, 21 Jun 2011 12:41:34 -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 gVraYuNgerfZ for ; Tue, 21 Jun 2011 12:41:33 -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 2A7A61F0C38 for ; Tue, 21 Jun 2011 12:41:33 -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 B062B21F1B for ; Tue, 21 Jun 2011 15:41:30 -0400 (EDT) Message-ID: <4E00F3EA.6020104@viagenie.ca> Date: Tue, 21 Jun 2011 15:41:30 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110320 Fedora/3.1.9-4.fc16 Lightning/1.0b3pre Thunderbird/3.1.9 MIME-Version: 1.0 To: "behave@ietf.org" X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [BEHAVE] NAT behaviour when port quota is reached 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, 21 Jun 2011 19:41:34 -0000 These two don't seem to agree on what is appropriate... RFC 5508: REQ-8: When a NAT device is unable to establish a NAT Session for a new transport-layer (TCP, UDP, ICMP, etc.) flow due to resource constraints or administrative restrictions, the NAT device SHOULD send an ICMP destination unreachable message, with a code of 13 (Communication administratively prohibited) to the sender, and drop the original packet. RFC 6146: If it is not possible to allocate an appropriate IPv4 transport address or create a BIB entry, then the packet is discarded. The NAT64 SHOULD send an ICMPv6 Destination Unreachable error message with Code 3 (Address Unreachable). Code 3 is a soft error according to RFC 5461. Any reason why they're not specifying the same code? Is there an errata to be filed? 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 Jun 24 15:24:16 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 D9A7C11E80E7 for ; Fri, 24 Jun 2011 15:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.449 X-Spam-Level: X-Spam-Status: No, score=-110.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AuHlCq313xFl for ; Fri, 24 Jun 2011 15:24:16 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2235711E809E for ; Fri, 24 Jun 2011 15:24:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=875; q=dns/txt; s=iport; t=1308954256; x=1310163856; h=from:to:subject:date:message-id:mime-version: content-transfer-encoding; bh=tJUHewcYhvryyW0r+SCEKwdSFBV2CWxWKquAYdIMw/c=; b=XrFplN6Vb7PSoXlQj2NWEsdWDfE4vDPw1Ihc2JtrvcYD/R6HWUlA9edO Ge0i44BYserotQDXebE38p/EmJ9AyCIybYjiDvuEYPb7jMRf8VIBXftnI qOCe8trGYnMVWV172/20w0F2JQMQYcSyEzX4htiLrVg40H8zhe7UkkvJj E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAGcOBU6rRDoG/2dsb2JhbABSmgONPneqLIEdngCGLQSHKZsE X-IronPort-AV: E=Sophos;i="4.65,421,1304294400"; d="scan'208";a="346905802" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-3.cisco.com with ESMTP; 24 Jun 2011 22:24:12 +0000 Received: from dwingWS (dhcp-128-107-104-36.cisco.com [128.107.104.36]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5OMOCl4024643 for ; Fri, 24 Jun 2011 22:24:12 GMT From: "Dan Wing" To: "Behave WG" Date: Fri, 24 Jun 2011 15:24:12 -0700 Message-ID: <04ac01cc32bd$71b7cb20$55276160$@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: AcwyvXGPp6n1gRPGRzOJF+HusHr8eQ== Content-Language: en-us Subject: [BEHAVE] IETF81 agenda 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, 24 Jun 2011 22:24:17 -0000 BEHAVE's agenda will be: http://www.ietf.org/proceedings/81/agenda/behave.html and is copied below for reference. IETF agenda is at https://datatracker.ietf.org/meeting/81/agenda.html -d ----- Wednesday, 15:10-16:10, 206 B (conflicts: sieve, atoca, avtext, cuss, cicm, nfsv4) 15:10 Note takers, agenda, existing milestones (Chairs, 5) 15:15 Large Scale NAT Requirements (TBD, 15) draft-ietf-behave-lsn-requirements 15:30 NAT64 Discovery Heuristic (Jouni Korhonen, 15) draft-ietf-behave-nat64-discovery-heuristic 15:45 Stateless Source Address Mapping for ICMPv6 Packets (Xing Li, 10) draft-xli-behave-icmp-address 15:55 Revealing hosts sharing an IP address using TCP option (Dan Wing, 5) draft-wing-nat-reveal-option From dwing@cisco.com Fri Jun 24 15:40:06 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 6BB3D11E810A for ; Fri, 24 Jun 2011 15:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.479 X-Spam-Level: X-Spam-Status: No, score=-110.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OaATkFfHGvl3 for ; Fri, 24 Jun 2011 15:40:05 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id D07A211E80F7 for ; Fri, 24 Jun 2011 15:40:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2434; q=dns/txt; s=iport; t=1308955205; x=1310164805; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=a+hBv+zOtq81yU9p3QUKQONoXmKZD4XkdKbveid5rE4=; b=X92nKI9EaglDzWW9Aw6GxJGjwbsUzP3zhbgohrQUkUx3h7x/iyNhFjpI OcrtkmOTjA10E3I3nYTPBh0SY/rgSa54fyGa/gz/N0Kgxjsusvr+w/E0M Ag/3MsRVmkkXakIHEIzi4s71RPv+AyaC0vja0ysyxVX8vHjJtrHKyL20x g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj8CAOARBU6rRDoI/2dsb2JhbABSmByBZ4YygUyFQHeIc6JbnX+DI4MKBIcpmwQ X-IronPort-AV: E=Sophos;i="4.65,422,1304294400"; d="scan'208";a="346912414" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 24 Jun 2011 22:40:05 +0000 Received: from dwingWS (dhcp-128-107-104-36.cisco.com [128.107.104.36]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5OMe5vO029687; Fri, 24 Jun 2011 22:40:05 GMT From: "Dan Wing" To: "'Simon Perreault'" , References: <4E00F3EA.6020104@viagenie.ca> In-Reply-To: <4E00F3EA.6020104@viagenie.ca> Date: Fri, 24 Jun 2011 15:40:05 -0700 Message-ID: <04b401cc32bf$a9deb930$fd9c2b90$@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: AcwwS0xwEKll1E62RP+zQFqLQyyQ6QCc1tYQ Content-Language: en-us Subject: Re: [BEHAVE] NAT behaviour when port quota is reached 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, 24 Jun 2011 22:40:06 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Simon Perreault > Sent: Tuesday, June 21, 2011 12:42 PM > To: behave@ietf.org > Subject: [BEHAVE] NAT behaviour when port quota is reached > > These two don't seem to agree on what is appropriate... > > RFC 5508: > > REQ-8: When a NAT device is unable to establish a NAT Session for a > new transport-layer (TCP, UDP, ICMP, etc.) flow due to resource > constraints or administrative restrictions, the NAT device SHOULD > send an ICMP destination unreachable message, with a code of 13 > (Communication administratively prohibited) to the sender, and drop > the original packet. > > RFC 6146: > > If it is not possible to allocate an appropriate IPv4 transport > address or create a BIB entry, then the packet is discarded. The > NAT64 SHOULD send an ICMPv6 Destination Unreachable error message > with Code 3 (Address Unreachable). > > Code 3 is a soft error according to RFC 5461. > > Any reason why they're not specifying the same code? Is there an errata > to be filed? I recall some discussion occurred on this difference. We need to reach a consensus on this, because a CGN will certainly hit this limit and we should have a consistent error message that all CGNs generate. (Which I suppose is part of the reason you are asking.) IMO, if a user hits a configured limit (e.g., 1000 ports), 'administratively prohibited' is a reasonable error. Afterall, the NAT may well have plenty of additional capacity for more mappings, but the NAT is administratively restricted from giving the user more than 1000 mappings. On the other hand, if a user hits a hard limit (e.g., consumes all of the memory allocated to mappings in the NAT), this isn't an 'administrative' limit but is rather an architectural limit (physical memory), and returning 'address unreachable' makes sense. But, there is probably no value in differentiating these two types of errors. Thoughts? -d > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From wwwrun@rfc-editor.org Sat Jun 25 23:17:41 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 7EEA621F850F for ; Sat, 25 Jun 2011 23:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.442 X-Spam-Level: X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[AWL=0.158, 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 DlVto5ZUwxoZ for ; Sat, 25 Jun 2011 23:17:41 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id 24F7F21F850E for ; Sat, 25 Jun 2011 23:17:41 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 11ABF98C50F; Sat, 25 Jun 2011 23:17:41 -0700 (PDT) To: derek.macdonald@gmail.com, bbl@lowekamp.net, ietfdbh@comcast.net, wes@mti-systems.com, dthaler@microsoft.com, dwing@cisco.com From: RFC Errata System Message-Id: <20110626061741.11ABF98C50F@rfc-editor.org> Date: Sat, 25 Jun 2011 23:17:41 -0700 (PDT) Cc: behave@ietf.org, jselbie@microsoft.com, rfc-editor@rfc-editor.org Subject: [BEHAVE] [Technical Errata Reported] RFC5780 (2844) 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, 26 Jun 2011 06:17:41 -0000 The following errata report has been submitted for RFC5780, "NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5780&eid=2844 -------------------------------------- Type: Technical Reported by: John Selbie Section: 7.5 Original Text ------------- RESPONSE-PORT is a 16-bit unsigned integer in network byte order followed by 2 bytes of padding. Allowable values of RESPONSE-PORT are 0-65536. Corrected Text -------------- RESPONSE-PORT is a 16-bit unsigned integer in network byte order followed by 2 bytes of padding. Allowable values of RESPONSE-PORT are 0-65535. Notes ----- The 16-bit unsigned int range is 0-65535 (0x0000 - 0xffff). 65536 can't be represented inside a a 16-bit. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5780 (draft-ietf-behave-nat-behavior-discovery-08) -------------------------------------- Title : NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN) Publication Date : May 2010 Author(s) : D. MacDonald, B. Lowekamp Category : EXPERIMENTAL Source : Behavior Engineering for Hindrance Avoidance Area : Transport Stream : IETF Verifying Party : IESG From internet-drafts@ietf.org Sun Jun 26 03:23: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 D2CBB21F8504; Sun, 26 Jun 2011 03:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 1baN5aalV8iA; Sun, 26 Jun 2011 03:23:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6126A21F84FD; Sun, 26 Jun 2011 03:23:40 -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: <20110626102340.6716.78965.idtracker@ietfa.amsl.com> Date: Sun, 26 Jun 2011 03:23:40 -0700 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action: draft-ietf-behave-sctpnat-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: Sun, 26 Jun 2011 10:23: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 : Stream Control Transmission Protocol (SCTP) Network Addr= ess Translation Author(s) : Randall R. Stewart Michael Tuexen Irene Ruengeler Filename : draft-ietf-behave-sctpnat-05.txt Pages : 26 Date : 2011-06-26 Stream Control Transmission Protocol [RFC4960] provides a reliable communications channel between two end-hosts in many ways similar to TCP [RFC0793]. With the widespread deployment of Network Address Translators (NAT), specialized code has been added to NAT for TCP that allows multiple hosts to reside behind a NAT and yet use only a single globally unique IPv4 address, even when two hosts (behind a NAT) choose the same port numbers for their connection. This additional code is sometimes classified as Network Address and Port Translation or NAPT. To date, specialized code for SCTP has NOT yet been added to most NATs so that only pure NAT is available. The end result of this is that only one SCTP capable host can be behind a NAT. This document describes an SCTP specific variant of NAT which provides similar features of NAPT in the single point and multi-point traversal scenario. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-sctpnat-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-sctpnat-05.txt From bbl@lowekamp.net Sun Jun 26 08:19: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 57F5C9E8005 for ; Sun, 26 Jun 2011 08:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 fEgRZzKQe+pi for ; Sun, 26 Jun 2011 08:19:34 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5D84A9E8004 for ; Sun, 26 Jun 2011 08:19:34 -0700 (PDT) Received: by eye13 with SMTP id 13so1582733eye.31 for ; Sun, 26 Jun 2011 08:19:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.15.214 with SMTP id f62mr3405614eef.178.1309101571459; Sun, 26 Jun 2011 08:19:31 -0700 (PDT) Received: by 10.14.100.143 with HTTP; Sun, 26 Jun 2011 08:19:31 -0700 (PDT) In-Reply-To: <20110626061741.11ABF98C50F@rfc-editor.org> References: <20110626061741.11ABF98C50F@rfc-editor.org> Date: Sun, 26 Jun 2011 11:19:31 -0400 Message-ID: From: Bruce Lowekamp To: RFC Errata System Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: behave@ietf.org, jselbie@microsoft.com, wes@mti-systems.com, dthaler@microsoft.com, dwing@cisco.com, derek.macdonald@gmail.com, ietfdbh@comcast.net Subject: Re: [BEHAVE] [Technical Errata Reported] RFC5780 (2844) 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, 26 Jun 2011 15:19:35 -0000 Should be verified Bruce On Sun, Jun 26, 2011 at 2:17 AM, RFC Errata System wrote: > > The following errata report has been submitted for RFC5780, > "NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN)"= . > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D5780&eid=3D2844 > > -------------------------------------- > Type: Technical > Reported by: John Selbie > > Section: 7.5 > > Original Text > ------------- > RESPONSE-PORT is a 16-bit unsigned integer in network byte order followed= by 2 bytes of padding. Allowable values of RESPONSE-PORT are 0-65536. > > Corrected Text > -------------- > RESPONSE-PORT is a 16-bit unsigned integer in network byte order followed= by 2 bytes of padding. Allowable values of RESPONSE-PORT are 0-65535. > > Notes > ----- > The 16-bit unsigned int range is 0-65535 (0x0000 - 0xffff). =C2=A065536 c= an't be represented inside a a 16-bit. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC5780 (draft-ietf-behave-nat-behavior-discovery-08) > -------------------------------------- > Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : NAT Behavior Dis= covery Using Session Traversal Utilities for NAT (STUN) > Publication Date =C2=A0 =C2=A0: May 2010 > Author(s) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : D. MacDonald, B. Lowekamp > Category =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: EXPERIMENTAL > Source =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Behavior Enginee= ring for Hindrance Avoidance > Area =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Transport > Stream =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: IETF > Verifying Party =C2=A0 =C2=A0 : IESG > From simon.perreault@viagenie.ca Sun Jun 26 08:41: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 0EE5A21F84A6 for ; Sun, 26 Jun 2011 08:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 0bI96xY6zyDV for ; Sun, 26 Jun 2011 08:41:27 -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 2708221F84A0 for ; Sun, 26 Jun 2011 08:41:27 -0700 (PDT) Received: from [192.168.1.34] (modemcable057.183-82-70.mc.videotron.ca [70.82.183.57]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 2850721F26; Sun, 26 Jun 2011 11:41:26 -0400 (EDT) Message-ID: <4E075325.30901@viagenie.ca> Date: Sun, 26 Jun 2011 11:41:25 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Dan Wing References: <4E00F3EA.6020104@viagenie.ca> <04b401cc32bf$a9deb930$fd9c2b90$@com> In-Reply-To: <04b401cc32bf$a9deb930$fd9c2b90$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: behave@ietf.org Subject: Re: [BEHAVE] NAT behaviour when port quota is reached 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, 26 Jun 2011 15:41:36 -0000 Le 24/06/2011 6:40 PM, Dan Wing a écrit : > I recall some discussion occurred on this difference. > > We need to reach a consensus on this, because a CGN will certainly > hit this limit and we should have a consistent error message that > all CGNs generate. (Which I suppose is part of the reason you > are asking.) Precisely. I started a new thread to ensure this issue gets the attention it deserves. > IMO, if a user hits a configured limit (e.g., 1000 ports), > 'administratively prohibited' is a reasonable error. Afterall, > the NAT may well have plenty of additional capacity for more > mappings, but the NAT is administratively restricted from giving > the user more than 1000 mappings. On the other hand, if a user > hits a hard limit (e.g., consumes all of the memory allocated > to mappings in the NAT), this isn't an 'administrative' limit > but is rather an architectural limit (physical memory), and > returning 'address unreachable' makes sense. > > But, there is probably no value in differentiating these two types > of errors. IMHO, what is important is that the error is soft. From the point of view of the TCP stack, both cases above should be handled exactly as when a packet is dropped by a router when its queue is full: it should retransmit. This is what's important. This implies that sending an ICMP error in the first place does not matter very much. Quoting RFC 792, "Some datagrams may still be undelivered without any report of their loss. The higher level protocols that use IP must implement their own reliability procedures if reliable communication is required." Furthermore, ICMP errors sent by the CGN are going to be rate limited so the TCP stack will have to deal with the "no ICMP error" case quite often. With all that said, we know that code 3 is specified to be a soft error, while we "guess" that 13 is soft (AFAIK). I'd rather err on the side of caution and pick 3 for the CGN requirements draft. And possibly file an errata against RFC 5508. Simon From dwing@cisco.com Sun Jun 26 11:41:47 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 090BF1F0C46 for ; Sun, 26 Jun 2011 11:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108 X-Spam-Level: X-Spam-Status: No, score=-108 tagged_above=-999 required=5 tests=[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 HgehTqQ2NVbG for ; Sun, 26 Jun 2011 11:41:46 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 634881F0C3B for ; Sun, 26 Jun 2011 11:41:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2443; q=dns/txt; s=iport; t=1309113706; x=1310323306; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=qq01/BHbXGVJ/8tNMALHCutqYNnTION8nqkib2j6vnE=; b=KTD2KweAdW7Lp4h7aHJ1jWO4d+AMTuF13Cxe+MFBj2QE+6yT8SPYj07n rjmVpKOwJn49PBKkJPWJytXVwZypK+3azIEObBuFPRTSFXKa4iq+eKY6y A4/RAkg5K7z1FIYQBKjG9DWqqDFTElN1gF4LmahTX6pmzIX88BKIVEbSb c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAAJ98B06rRDoI/2dsb2JhbABSmBmBaI1Gd6tOnQuDI4MNBIcsmxI X-IronPort-AV: E=Sophos;i="4.65,428,1304294400"; d="scan'208";a="470191543" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-1.cisco.com with ESMTP; 26 Jun 2011 18:41:46 +0000 Received: from dwingWS ([10.89.11.163]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5QIfj3j023234; Sun, 26 Jun 2011 18:41:45 GMT From: "Dan Wing" To: "'Simon Perreault'" References: <4E00F3EA.6020104@viagenie.ca> <04b401cc32bf$a9deb930$fd9c2b90$@com> <4E075325.30901@viagenie.ca> In-Reply-To: <4E075325.30901@viagenie.ca> Date: Sun, 26 Jun 2011 11:41:44 -0700 Message-ID: <05e201cc3430$b3758600$1a609200$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acw0F4P6jkMW+KpTQ9uKZPSnR5aQKQAGR+vQ Content-Language: en-us Cc: behave@ietf.org Subject: Re: [BEHAVE] NAT behaviour when port quota is reached 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, 26 Jun 2011 18:41:47 -0000 > -----Original Message----- > From: Simon Perreault [mailto:simon.perreault@viagenie.ca] > Sent: Sunday, June 26, 2011 8:41 AM > To: Dan Wing > Cc: behave@ietf.org > Subject: Re: [BEHAVE] NAT behaviour when port quota is reached >=20 > Le 24/06/2011 6:40 PM, Dan Wing a =E9crit : > > I recall some discussion occurred on this difference. > > > > We need to reach a consensus on this, because a CGN will certainly > > hit this limit and we should have a consistent error message that > > all CGNs generate. (Which I suppose is part of the reason you > > are asking.) >=20 > Precisely. I started a new thread to ensure this issue gets the > attention it deserves. >=20 > > IMO, if a user hits a configured limit (e.g., 1000 ports), > > 'administratively prohibited' is a reasonable error. Afterall, > > the NAT may well have plenty of additional capacity for more > > mappings, but the NAT is administratively restricted from giving > > the user more than 1000 mappings. On the other hand, if a user > > hits a hard limit (e.g., consumes all of the memory allocated > > to mappings in the NAT), this isn't an 'administrative' limit > > but is rather an architectural limit (physical memory), and > > returning 'address unreachable' makes sense. > > > > But, there is probably no value in differentiating these two types > > of errors. >=20 > IMHO, what is important is that the error is soft. From the point of > view of the TCP stack, both cases above should be handled exactly as > when a packet is dropped by a router when its queue is full: it should > retransmit. This is what's important. >=20 > This implies that sending an ICMP error in the first place does not > matter very much. Quoting RFC 792, "Some datagrams may still be > undelivered without any report of their loss. The higher level > protocols that use IP must implement their own reliability procedures > if > reliable communication is required." Furthermore, ICMP errors sent by > the CGN are going to be rate limited so the TCP stack will have to = deal > with the "no ICMP error" case quite often. >=20 > With all that said, we know that code 3 is specified to be a soft > error, > while we "guess" that 13 is soft (AFAIK). I'd rather err on the side = of > caution and pick 3 for the CGN requirements draft. And possibly file = an > errata against RFC 5508. As an individual, I agree with that analysis. -d From iljitsch@muada.com Mon Jun 27 09:17: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 54F3921F85F0; Mon, 27 Jun 2011 09:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.785 X-Spam-Level: X-Spam-Status: No, score=-101.785 tagged_above=-999 required=5 tests=[AWL=-0.815, 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 9jTvf0xWFjHX; Mon, 27 Jun 2011 09:17:33 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id 2E50A21F85E8; Mon, 27 Jun 2011 09:17:31 -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 p5RGHu7V085279 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 27 Jun 2011 18:17:57 +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: <04C1AFDBEA554F3FA5FDD978C1682D6E@davidPC> Date: Mon, 27 Jun 2011 18:17:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <817780D4-1CF0-4A5A-90A8-E8BF98A2274F@muada.com> References: <04C1AFDBEA554F3FA5FDD978C1682D6E@davidPC> To: David Harrington X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-behave-ftp64@tools.ietf.org, fgont@acm.org, "behave@ietf.orgWG WG" , Pekka Savola , TSV Area , "behave-chairs@tools.ietf.org Chairs" , TSV Dir , draft-ietf-behave-ftp64.all@tools.ietf.org, Fernando Gont Subject: Re: [BEHAVE] FW: Last Call: (An FTP ALG for IPv6-to-IPv4 translation) to Proposed Standard 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, 27 Jun 2011 16:17:34 -0000 FTP ALG implementers: please respond if you have an opinion, some stuff = below may make your life harder! (This is a response to two different = messages.) On 3 jun 2011, at 14:06, David Harrington wrote: > Can you address these issues? > Do you have any other comments you know of that need to be included in > a new rev? There were three reviews. See below for two, I'm trying to clear = something up about the other more directly. On 30 mei 2011, at 11:10, Pekka Savola wrote: > This is an ops-dir review of draft-ietf-behave-ftp64-10. > substantial comments > -------------------- > The document does not mention or discuss LPRT and LPSV. Is that = intentional? > The IANA registry says these are now obsolete, but RFC1639 is still > experimental and no document has (formally) obsoleted these. I managed to overlook RFC 1639, and it wasn't brought up by anyone else = during the process. Apparently wu-ftpd implements this and curl used to, = but both failed to see any real-world usage so I think we can ignore = this without creating problems. > Telnet option negotiation attempts by either the client or the > server, except for those allowed by [RFC1123], MUST be rejected by > the FTP ALG without relaying those attempts. This avoids the > situation where the client and the server negotiate Telnet options > that are unimplemented by the FTP ALG. > ... what does "rejected" mean exactly? Does the ALG send back to > the negotiation attempter some error code? Does it abort the = connection? > ignore these options? strip them out when connecting to the other = end? What I had in mind was reply with a "DON'T". Is this text more clear? Telnet option negotiation attempts by either the client or the server, except for those allowed by [RFC1123], MUST be rejected by the FTP ALG without relaying those attempts. For the purpose of Telnet option negotiation, an FTP ALG MUST follow the behavior of an FTP server as specified in [RFC1123] section 4.1.2.12. This... That section says: 4.1.2.12 Connections: RFC-959 Section 5.2 The words "and the port used" in the second paragraph of this section of RFC-959 are erroneous (historical), and they should be ignored. On a multihomed server host, the default data transfer port (L-1) MUST be associated with the same local IP address as the corresponding control connection to port L. A user-FTP MUST NOT send any Telnet controls other than SYNCH and IP on an FTP control connection. In particular, it MUST NOT attempt to negotiate Telnet options on the control connection. However, a server-FTP MUST be capable of accepting and refusing Telnet negotiations (i.e., sending DONT/WONT). DISCUSSION: Although the RFC says: "Server- and User- processes should follow the conventions for the Telnet protocol...[on the control connection]", it is not the intent that Telnet option negotiation is to be employed. > 8. Default port 20 translation > If the client does not issue an EPSV/PASV or EPRT/PORT command prior > to initiating a file transfer, it is invoking the default active FTP > behavior where the server sets up a TCP session towards the client. > In this situation, the source port number is the default FTP data > port (port 20) and the destination port is the port the client uses > as the source port for the control channel session. > .. is it? I thought the source port used by the server is orthogonal = to > whether pasv/port is issued. AFAIK, multiple FTP server = implementations > never use port 20. But I have not recently tested this myself. RFC 959: 3.2. ESTABLISHING DATA CONNECTIONS The mechanics of transferring data consists of setting up the data connection to the appropriate ports and choosing the parameters for transfer. Both the user and the server-DTPs have a default data port. The user-process default data port is the same as the control connection port (i.e., U). The server-process default data port is the port adjacent to the control connection port (i.e., L-1). > The ALG MUST enable or disable EPSV to PASV translation as = requested. > If EPRT to PORT translation is supported, ALGS ENABLE64 SHOULD = enable > it and ALGS DISABLE64 SHOULD disable it along with enabling or > disabling EPSV to PASV translation, respectively. If EPRT to PORT > translation is not supported, ALGS ENABLE64 only enables EPSV to = PASV > translation. > .. what does this SHOULD..along with.. mean? I read it so that it's = OK > that for "ALGS DISABLE64" EPSV->PASV is disabled but EPRT->PORT is not > disabled? A different way to read it would be that both EPSV->PASV = and > EPRT->PORT are SHOULDs. I think what it says is that it's optional to disable PORT->EPRT upon = DISABLE64. Enabling is optional because the feature is optional, but I = guess if you have the feature disabling should be mandatory, so = SHOULD->MUST: The ALG MUST enable or disable EPSV to PASV translation as requested. If EPRT to PORT translation is supported, ALGS ENABLE64 MUST enable it and ALGS DISABLE64 MUST disable it along with... Agree? > A survey done in April of 2009 of 25 randomly picked and/or well- > known FTP sites reachable over IPv4 showed that only 12 of them > supported EPSV over IPv4. > .. fwiw, Dan Wing redid this test on 18 May 2011, reporting on behave = list. > the results didn't differ much (I didn't look at the numbers), but if = you > want to update this, now would be the chance. I don't see the need to. > If > such a multi-purpose ALG forbids the use of the AUTH command for > policy reasons, the side effect of making the ALG stop performing = the > translations described here, as well as other possible interventions > related to IPv6-to-IPv4 translation, MUST be retained even if the = ALG > responds to the AUTH command with an error and does not propagate = the > command to the server. > .. I had a hard time following what this one sentence includign a MUST > actually requires. Maybe break down to more easily digestible = sentences? What about this: If such a multi-purpose ALG forbids the use of the AUTH command for policy reasons, the side effect of the AUTH command as described in this document MUST be retained. In other words, if the ALG does not propagate = the AUTH command to the server, the ALG MUST still stop all possible = interventions related to IPv6-to-IPv4 translation. This is true for the = remaining duration of the control channel session, and applies even if the ALG responds to the AUTH command with an error. > [Bernstein] > Bernstein, D., "PASV security and PORT security", 2000, > . > .. this reference is not cited in the doc, add or remove? I'll remove it. On 4 jun 2011, at 0:16, Fernando Gont wrote: > I've reviewed this document as part of the transport area = directorate's > ongoing effort to review key IETF documents. > * Section 1, page 3: > In 5 cases, issuing the EPSV > command to the server led to a significant delay, in 3 cases = followed > by a control channel reset. > Could you please clarify what was the cause of the delay? And, btw, = have > you guys put the details of your results publicly available somewhere? What about the following text: Due to lack of additional information, it is impossible to determine = conclusively why certain FTP servers reset the control channel = connection some time after issueing an EPSV command. However, a = reasonable explanation would be that these FTP servers are located = behind application-aware firewalls which monitor the control channel = session and only allow the creation of data channel sessions to the = ports listed in the responses to PASV (and maybe PORT) commands. As the = response to an EPSV command is different (a 229 code rather than a 227 = code), a firewall that is unaware of the EPSV command would block the = subsequent data channel setup attempt, after which the FTP server may = decide to terminate the control channel session which isn't progressing = the way it should. > * Section 1, page 3-4: > Clients that want to engage in more complex behavior, such as = server- > to-server transfers, may make an FTP application layer gateway (ALG) > go into transparent mode by issuing AUTH or ALGS commands as > explained in Section 5. > I thought server-to-server transfer had been banned for many years now > (it was exploited for address scan purposes). Am I missing something? Do you have a reference? As it's only listed here as an example of something that isn't = addressed, I don't think it's an issue to include this here. > * Section 5: > In the second case, an implementation MUST have the ability to track > and update TCP sequence numbers when translating packets as well as > the ability to break up packets into smaller packets after > [....] > What about the TCP URG flag and the Urgent Pointer? FTP is one of the > few legacy applications that make use of TCP's urgent mode. And while > use in new applications is deprecated, and TCP urgent mode itself is > unreliable (see RFC 6093), you should make an explicit decision about > what to do with TCP urgent mode when used for the FTP control channel. The word "urgent" isn't mentioned in RFC 959 or the FTP-related part of = RFC 1123. But RFC 959 does mention using the Telnet SYNCH signal, which = involves using urgent data. However, it looks like it's legal to ignore = the urgent pointer, from RFC 793: TCP also provides a means to communicate to the receiver of data that at some point further along in the data stream than the receiver is currently reading there is urgent data. TCP does not attempt to define what the user specifically does upon being notified of pending urgent data, but the general notion is that the receiving process will take action to process the urgent data quickly > When packets are translated individually, the ALG should update the > Urgent Pointer if/where necessary. If the ALG terminates the IPv6 TCP > session, there's the question of whether urgent mode should be = "copied" > from the IPv6 session to the IPv4 session. I think it's not worth the trouble and unlikely to be tested well, so I = would be in favor of clearing the URG flag. Any objections? > * Section 5.1, page 7: > For the time being, ALG implementations may employ > one of the following strategies regarding LANG negotiation > Should you s/may/MAY/? Not really. I'll see what the RFC Editor says. > * Section 5.1, page 8: > 3. Block LANG negotiation by translating the LANG command to a NOOP > command, and translating the resulting 200 response into a > response appropriate for unsupported commands, such as 500. = Text > is sent in the default language. > I think you should mandate which exact code the 200 should be = translated > to, rather than just provide an example. Let's make it a 502 then. > 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. > Remove the comma between "today" and "others" Ok. > translators > are used to bridge that gap, FTP is made to work through these > translators as best it can. > s/as best as it can/to the best possible extent/? Why not. > * Section 5.1 (page 7) and elsewhere: > So the situation where the client and server try to > negotiate a language that the ALG doesn't support can't be avoided. > Expand doesn't to "does not", "can't" to "cannot", etc. Hm, the 425 code has "can't" in it. I'll leave this open and see what = the RFC Editor says. > * Section 5.1, page 8: > Note that [RFC2640] section 3.1 specifies new handling for spaces = and > the CR character in path names. > Rephrase to "Note that Section 3.1 of [RFC2640]..." I adopted the word order but not the capitalization. > * Section 11, page 12: > ALGs MUST support the new ALGS (ALG status) command that allows > command MUST be passed on to the server without modification, and = the > clients to query and set the ALG's status. > I had trouble parsing this sentence. This is the text that is in -10: ALGs MUST support the new ALGS (ALG status) command that allows clients to query and set the ALG's status. FTP servers (as opposed to ALGs) MUST NOT perform any actions upon receiving the ALGS command. FTP servers MUST still send a response, however. If FTP servers recognize the ALGS command, the best course of action would be to return a 202 response: Apparently two lines got lost at your end. > * Section 11, page 12: > A client can use the ALGS command to request the ALG's status and to > enable and disable EPSV to PASV and, if implemented, EPRT to PORT > translation. > Please rephrase to "...disable EPSV to PASV translation and, if > implemented, EPRT to PORT translation". Ok. Both of you, thanks for the reviews.= From bschlies@cisco.com Mon Jun 27 10:01: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 7EE9A11E810B for ; Mon, 27 Jun 2011 10:01:02 -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 ehreQz9bVFOf for ; Mon, 27 Jun 2011 10:01:01 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id E838711E80FD for ; Mon, 27 Jun 2011 10:01:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=997; q=dns/txt; s=iport; t=1309194061; x=1310403661; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=vTw4QXPxltd/DAZBv2g7+qFGJA1zI0/ysaA2gurkWPQ=; b=kueHjPvXNQIbzwzOWhIfLlvkNhXgPdl/SMLsHsXEkhjp85S2p+93+Do1 UEoLj29/jBmkyrwOo1bBqa3ziLp/2KF2bsJaEmC1dx6zSPWFqiBzomxeK R5invbvT7OCXJwbDG49DosbuF69SCNvA5XwrO6gf/VE2GELyJr5GZknVX s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIS1CE6tJV2a/2dsb2JhbABSpy53qladeIMjgw0EhyyKV4R3i0I X-IronPort-AV: E=Sophos;i="4.65,433,1304294400"; d="scan'208";a="722853399" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by sj-iport-6.cisco.com with ESMTP; 27 Jun 2011 17:01:01 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5RH11Kv012369; Mon, 27 Jun 2011 17:01:01 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 27 Jun 2011 12:01:01 -0500 Received: from 10.21.125.90 ([10.21.125.90]) by XMB-RCD-206.cisco.com ([72.163.62.213]) via Exchange Front-End Server email.cisco.com ([128.107.191.114]) with Microsoft Exchange Server HTTP-DAV ; Mon, 27 Jun 2011 17:01:00 +0000 User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Mon, 27 Jun 2011 12:03:22 -0500 From: Benson Schliesser To: Dan Wing , "'Simon Perreault'" Message-ID: Thread-Topic: [BEHAVE] NAT behaviour when port quota is reached Thread-Index: Acw0F4P6jkMW+KpTQ9uKZPSnR5aQKQAGR+vQAC7ex5I= In-Reply-To: <05e201cc3430$b3758600$1a609200$@com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 27 Jun 2011 17:01:01.0125 (UTC) FILETIME=[CACC5750:01CC34EB] Cc: behave@ietf.org Subject: Re: [BEHAVE] NAT behaviour when port quota is reached 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, 27 Jun 2011 17:01:02 -0000 On 6/26/11 1:41 PM, "Dan Wing" wrote: >> ... >> With all that said, we know that code 3 is specified to be a soft >> error, >> while we "guess" that 13 is soft (AFAIK). I'd rather err on the side of >> caution and pick 3 for the CGN requirements draft. And possibly file an >> errata against RFC 5508. > > As an individual, I agree with that analysis. Same here. For a point of reference, I looked quickly at the latest stable Linux source (caveat: I'm no Linux kernel hacker - somebody should verify my comment) and it appears to handle both sub-codes 3 and 13 the same. Of course, I'm not sure that it handles packet loss the same as an ICMP unreach; I think packet loss will result in a slower connection death. In the case of a connection failure via CGN, I think it's good to send an ICMP message if possible to indicate failure quickly, with a fallback to "dropped packet" behavior if the ICMP rate is too high / being policed. Cheers, -Benson From jhw@apple.com Mon Jun 27 17:19:00 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 F2E169E800A for ; Mon, 27 Jun 2011 17:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 njmqsQ6DnmUL for ; Mon, 27 Jun 2011 17:18:59 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 95ED59E8009 for ; Mon, 27 Jun 2011 17:18:59 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay13.apple.com ([17.128.113.29]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LNH00JQR4V74M31@mail-out.apple.com> for behave@ietf.org; Mon, 27 Jun 2011 17:18:59 -0700 (PDT) X-AuditID: 1180711d-b7c5fae000001427-86-4e091ddfded9 Received: from jimbu (jimbu.apple.com [17.151.62.37]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay13.apple.com (Apple SCV relay) with SMTP id FD.72.05159.FDD190E4; Mon, 27 Jun 2011 17:18:39 -0700 (PDT) Received: from [17.193.13.64] (unknown [17.193.13.64]) by cardamom.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LNH00CU14VMWU50@cardamom.apple.com> for behave@ietf.org; Mon, 27 Jun 2011 17:18:58 -0700 (PDT) From: james woodyatt In-reply-to: <03c501cc0539$e3808ff0$aa81afd0$@com> Date: Mon, 27 Jun 2011 17:18:58 -0700 Message-id: <7379A7E2-DDF1-4023-8CF3-B8DA629CF61C@apple.com> References: <03c501cc0539$e3808ff0$aa81afd0$@com> To: behave@ietf.org X-Mailer: Apple Mail (2.1244.3) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJLMWRmVeSWpSXmKPExsUiON1OVfe+LKefQeMCBYupC6+wOzB6LFny kymAMYrLJiU1J7MstUjfLoErY96UVWwFt5krZk/uYW1g/MXUxcjJISFgIvFt+mRWCFtM4sK9 9WxdjFwcQgKtTBKLVi5kBknwCghK/Jh8j6WLkYODWUBe4uB5WZAws4CWxPdHrSwQ9bOZJM6/ Pc8IkhAWcJd40nwYbCibgIrEt8t3wZZxChhJLNj0Cmwmi4CqRPvCd4wQ820kVv88xgZiCwkY Svw92wVWIyIgLHHj9zMWiOPkJRa3fGacwMg/C8lJsxBOmoXkpAWMzKsYBYtScxIrDY31EgsK clL1kvNzNzGCAqyhUHYH4/6f/IcYBTgYlXh4Vy3j8BNiTSwrrsw9xCjBwawkwsugDRTiTUms rEotyo8vKs1JLT7EKM3BoiTOe3XNJ18hgfTEktTs1NSC1CKYLBMHp1QDI/vX6Y+Y1ZOnM5w9 X7bm1dSYSZuyX/+rudVlqPdoC7/iCdFzK284dRtJFb3jnpW44/AJay2NlkmGS3UzHl7MPbPq dO29OxNvlja/5Zj0817yYx4uz4/Wt/s6RCLeJr27aib8UMp5negSF+M0bTcBtYCm569rts5j 3VLL42zWv7Ii/9p54RDJB0osxRmJhlrMRcWJAA9507wsAgAA Subject: Re: [BEHAVE] IPv6/IPv4 translation documents published as RFCs 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, 28 Jun 2011 00:19:00 -0000 On Apr 27, 2011, at 17:19 , Dan Wing wrote: > > Congratulations to the WG and authors for today's publication of BEHAVE's > IPv6/IPv4 translation documents. This provides the industry with necessary > IPv6 transition tools, and these specifications were finished with the > urgency necessary due to IPv4 exhaustion. Great job. Yes, absolutely. Thank you all very much. -- james woodyatt member of technical staff, core os networking From ietfdbh@comcast.net Tue Jun 28 20:56: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 D634411E808E for ; Tue, 28 Jun 2011 20:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.261 X-Spam-Level: X-Spam-Status: No, score=-102.261 tagged_above=-999 required=5 tests=[AWL=0.338, 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 R16GtoT8uOxC for ; Tue, 28 Jun 2011 20:56:19 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1D47411E808D for ; Tue, 28 Jun 2011 20:56:19 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta10.westchester.pa.mail.comcast.net with comcast id 1fvd1h0051ei1Bg5AfwKba; Wed, 29 Jun 2011 03:56:19 +0000 Received: from davidPC ([67.189.235.106]) by omta24.westchester.pa.mail.comcast.net with comcast id 1fwH1h00H2JQnJT3kfwHgY; Wed, 29 Jun 2011 03:56:18 +0000 From: "David Harrington" To: "'Dan Wing'" , "'Behave WG'" References: <04bd01cc27d5$e87375e0$b95a61a0$@com> In-Reply-To: <04bd01cc27d5$e87375e0$b95a61a0$@com> Date: Tue, 28 Jun 2011 23:56:06 -0400 Message-ID: <8664C77032A6418A98A48DA3A34789F0@davidPC> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.1.7600.16807 Thread-index: Acwn1eguJRRv7kJmQ+Kd8tITmtQ4RwOOTDig Cc: behave-chairs@tools.ietf.org, 'Dave Thaler' Subject: Re: [BEHAVE] BEHAVE presentations at IETF81 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, 29 Jun 2011 03:56:19 -0000 Hi, FYI. Your email discusses drafts going as AD-sponsored rather than as WG drafts. The IESG has been having discussions about AD-sponsored drafts. These take up an inordinate amount of an AD's time, and a number of ADs prefer not to do AD-sponsored drafts as a result. I am one of those ADs. It is better to have drafts handled through WGs, to get community review. If the relevant community (the WG) thinks a draft isn't worth working on, I am not likely to want to sponsor such a draft. Just so authors and the WG know ... David Harrington Director, IETF Transport Area ietfdbh@comcast.net (preferred for ietf) dbharrington@huaweisymantec.com +1 603 828 1401 (cell) > -----Original Message----- > From: behave-bounces@ietf.org > [mailto:behave-bounces@ietf.org] On Behalf Of Dan Wing > Sent: Friday, June 10, 2011 9:22 PM > To: Behave WG > Cc: behave-chairs@tools.ietf.org; 'Dave Thaler' > Subject: [BEHAVE] BEHAVE presentations at IETF81 > > Hi. > > For IETF81, we need to have draft agendas to our area > director to get agenda > time. > > > ********************************************************** > ** If you are planning to present a non-working group ** > ** document during the BEHAVE session at IETF81, send ** > ** email to behave-chairs@tools.ietf.org by ** > ** Wednesday, June 15. ** > ********************************************************** > > > From our working group active documents list > at http://tools.ietf.org/wg/behave, I expect we would have an > agenda covering these items: > > * draft-ietf-behave-64-analysis, no presentation (was WGLC'd) > > * draft-ietf-behave-lsn-requirements, 20 minutes > > * draft-ietf-behave-nat64-discovery-heuristic, 20 minutes > > * draft-ietf-behave-nat64-learn-analysis, no presentation > > * draft-ietf-behave-sctpnat, no presentation > > * draft-ietf-behave-sctpnat, no presentation (was WGLC'd) > > > of the "Related Active Documents (not working group > documents)", here are my > thoughts: > > * draft-boucadair-behave-bittorrent-address-sharing -- I > believe this was > going to be published AD-sponsored, unless there is interest > in the working > group on this document? If folks want to look at it, and > decide if they > could provide peer review, we might consider adopting this as > a WG document. > Please let me know. > > * draft-sivakumar-behave-nat-logging was requested to become > a WG document. > There was some feedback which I believe has not yet been > integrated into the > document. After that feedback is integrated, a presentation > might be a good > idea to determine if there is interest in adopting this as a > WG document. > > * The various multicast documents with -behave- in their > names should wait > for the outcome of the multicast BoF, to see if there is > interest in moving > forward with multicast translation. > > > If there are other things to discuss, send the chairs email. > > > Right now, it appears we might only need 1.0 or 1.5 hours of > meeting time. > > -d > > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From zhengyli@cisco.com Thu Jun 30 00:30: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 59B8F21F86A4; Thu, 30 Jun 2011 00:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.969 X-Spam-Level: X-Spam-Status: No, score=-8.969 tagged_above=-999 required=5 tests=[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 gsiSLJoHcoGk; Thu, 30 Jun 2011 00:30:57 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id C69D821F869C; Thu, 30 Jun 2011 00:30:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=zhengyli@cisco.com; l=14340; q=dns/txt; s=iport; t=1309419057; x=1310628657; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=m1oJffSywAc2r1JKOPPATBFeUitOq3e7Y1YP4CHM5JU=; b=B3NVfwv7hWlZIxaF9UvL2Xr7vBviQBD9mx2Tya4GMAH0Rwws37EZavSy t/ojatoHBdibPrnmuhPCxp99m3C0WuU3sYUliPsx4hGBJRPp7pfrw4uE+ 6Ylxlcn7CpsBUZxb+UslPKW87Kk479aUdS0k7a0Wyzaex9888opraheU4 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAPwkDE5Io8UR/2dsb2JhbABSp013qiqeDIYwBIc4imuEdYtD X-IronPort-AV: E=Sophos;i="4.65,449,1304294400"; d="scan'208";a="98948280" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-1.cisco.com with ESMTP; 30 Jun 2011 07:30:50 +0000 Received: from [64.104.167.59] ([64.104.167.59]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5U7UgBU014117; Thu, 30 Jun 2011 07:30:44 GMT User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Thu, 30 Jun 2011 15:30:38 +0800 From: Rockson Li To: Iljitsch van Beijnum , David Harrington Message-ID: Thread-Topic: [BEHAVE] FW: Last Call: (An FTP ALG for IPv6-to-IPv4 translation) to Proposed Standard In-Reply-To: <817780D4-1CF0-4A5A-90A8-E8BF98A2274F@muada.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: draft-ietf-behave-ftp64@tools.ietf.org, fgont@acm.org, "behave@ietf.orgWG WG" , Pekka Savola , TSV Area , "behave-chairs@tools.ietf.org Chairs" , TSV Dir , draft-ietf-behave-ftp64.all@tools.ietf.org, Fernando Gont Subject: Re: [BEHAVE] FW: Last Call: (An FTP ALG for IPv6-to-IPv4 translation) to Proposed Standard 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, 30 Jun 2011 07:30:59 -0000 |The document does not mention or discuss LPRT and LPSV. Is that intentional? |The IANA registry says these are now obsolete, but RFC1639 is still |experimental and no document has (formally) obsoleted these. [RL] It looks like sec 2.5 of RFC5797 has obsoleted those two commands. Regards, -Rockson On 6/28/11 12:17 AM, "Iljitsch van Beijnum" wrote: >FTP ALG implementers: please respond if you have an opinion, some stuff >below may make your life harder! (This is a response to two different >messages.) > >On 3 jun 2011, at 14:06, David Harrington wrote: > >> Can you address these issues? >> Do you have any other comments you know of that need to be included in >> a new rev? > >There were three reviews. See below for two, I'm trying to clear >something up about the other more directly. > >On 30 mei 2011, at 11:10, Pekka Savola wrote: > >> This is an ops-dir review of draft-ietf-behave-ftp64-10. > >> substantial comments >> -------------------- > >> The document does not mention or discuss LPRT and LPSV. Is that >>intentional? >> The IANA registry says these are now obsolete, but RFC1639 is still >> experimental and no document has (formally) obsoleted these. > >I managed to overlook RFC 1639, and it wasn't brought up by anyone else >during the process. Apparently wu-ftpd implements this and curl used to, >but both failed to see any real-world usage so I think we can ignore this >without creating problems. > >> Telnet option negotiation attempts by either the client or the >> server, except for those allowed by [RFC1123], MUST be rejected by >> the FTP ALG without relaying those attempts. This avoids the >> situation where the client and the server negotiate Telnet options >> that are unimplemented by the FTP ALG. > >> ... what does "rejected" mean exactly? Does the ALG send back to >> the negotiation attempter some error code? Does it abort the >>connection? >> ignore these options? strip them out when connecting to the other end? > >What I had in mind was reply with a "DON'T". Is this text more clear? > > Telnet option negotiation attempts by either the client or the > server, except for those allowed by [RFC1123], MUST be rejected by > the FTP ALG without relaying those attempts. For the purpose of > Telnet option negotiation, an FTP ALG MUST follow the behavior of > an FTP server as specified in [RFC1123] section 4.1.2.12. This... > >That section says: > > 4.1.2.12 Connections: RFC-959 Section 5.2 > > The words "and the port used" in the second paragraph of > this section of RFC-959 are erroneous (historical), and they > should be ignored. > > On a multihomed server host, the default data transfer port > (L-1) MUST be associated with the same local IP address as > the corresponding control connection to port L. > > A user-FTP MUST NOT send any Telnet controls other than > SYNCH and IP on an FTP control connection. In particular, it > MUST NOT attempt to negotiate Telnet options on the control > connection. However, a server-FTP MUST be capable of > accepting and refusing Telnet negotiations (i.e., sending > DONT/WONT). > > DISCUSSION: > Although the RFC says: "Server- and User- processes > should follow the conventions for the Telnet > protocol...[on the control connection]", it is not the > intent that Telnet option negotiation is to be > employed. > >> 8. Default port 20 translation > >> If the client does not issue an EPSV/PASV or EPRT/PORT command prior >> to initiating a file transfer, it is invoking the default active FTP >> behavior where the server sets up a TCP session towards the client. >> In this situation, the source port number is the default FTP data >> port (port 20) and the destination port is the port the client uses >> as the source port for the control channel session. > >> .. is it? I thought the source port used by the server is orthogonal to >> whether pasv/port is issued. AFAIK, multiple FTP server implementations >> never use port 20. But I have not recently tested this myself. > >RFC 959: > > 3.2. ESTABLISHING DATA CONNECTIONS > > The mechanics of transferring data consists of setting up the data > connection to the appropriate ports and choosing the parameters > for transfer. Both the user and the server-DTPs have a default > data port. The user-process default data port is the same as the > control connection port (i.e., U). The server-process default > data port is the port adjacent to the control connection port > (i.e., L-1). > >> The ALG MUST enable or disable EPSV to PASV translation as requested. >> If EPRT to PORT translation is supported, ALGS ENABLE64 SHOULD enable >> it and ALGS DISABLE64 SHOULD disable it along with enabling or >> disabling EPSV to PASV translation, respectively. If EPRT to PORT >> translation is not supported, ALGS ENABLE64 only enables EPSV to PASV >> translation. > >> .. what does this SHOULD..along with.. mean? I read it so that it's OK >> that for "ALGS DISABLE64" EPSV->PASV is disabled but EPRT->PORT is not >> disabled? A different way to read it would be that both EPSV->PASV and >> EPRT->PORT are SHOULDs. > >I think what it says is that it's optional to disable PORT->EPRT upon >DISABLE64. Enabling is optional because the feature is optional, but I >guess if you have the feature disabling should be mandatory, so >SHOULD->MUST: > > The ALG MUST enable or disable EPSV to PASV translation as requested. > If EPRT to PORT translation is supported, ALGS ENABLE64 MUST enable > it and ALGS DISABLE64 MUST disable it along with... > >Agree? > >> A survey done in April of 2009 of 25 randomly picked and/or well- >> known FTP sites reachable over IPv4 showed that only 12 of them >> supported EPSV over IPv4. > >> .. fwiw, Dan Wing redid this test on 18 May 2011, reporting on behave >>list. >> the results didn't differ much (I didn't look at the numbers), but if >>you >> want to update this, now would be the chance. > >I don't see the need to. > >> If >> such a multi-purpose ALG forbids the use of the AUTH command for >> policy reasons, the side effect of making the ALG stop performing the >> translations described here, as well as other possible interventions >> related to IPv6-to-IPv4 translation, MUST be retained even if the ALG >> responds to the AUTH command with an error and does not propagate the >> command to the server. > >> .. I had a hard time following what this one sentence includign a MUST >> actually requires. Maybe break down to more easily digestible >>sentences? > >What about this: > >If such a multi-purpose ALG forbids the use of the AUTH command for >policy reasons, the side effect of the AUTH command as described in this >document MUST be retained. In other words, if the ALG does not propagate >the AUTH command to the server, the ALG MUST still stop all possible >interventions related to IPv6-to-IPv4 translation. This is true for the >remaining duration >of the control channel session, and applies even if the ALG >responds to the AUTH command with an error. > >> [Bernstein] >> Bernstein, D., "PASV security and PORT security", 2000, >> . > >> .. this reference is not cited in the doc, add or remove? > >I'll remove it. > > >On 4 jun 2011, at 0:16, Fernando Gont wrote: > >> I've reviewed this document as part of the transport area directorate's >> ongoing effort to review key IETF documents. > > >> * Section 1, page 3: >> In 5 cases, issuing the EPSV >> command to the server led to a significant delay, in 3 cases followed >> by a control channel reset. > >> Could you please clarify what was the cause of the delay? And, btw, have >> you guys put the details of your results publicly available somewhere? > >What about the following text: > >Due to lack of additional information, it is impossible to determine >conclusively why certain FTP servers reset the control channel connection >some time after issueing an EPSV command. However, a reasonable >explanation would be that these FTP servers are located behind >application-aware firewalls which monitor the control channel session and >only allow the creation of data channel sessions to the ports listed in >the responses to PASV (and maybe PORT) commands. As the response to an >EPSV command is different (a 229 code rather than a 227 code), a firewall >that is unaware of the EPSV command would block the subsequent data >channel setup attempt, after which the FTP server may decide to terminate >the control channel session which isn't progressing the way it should. > >> * Section 1, page 3-4: >> Clients that want to engage in more complex behavior, such as server- >> to-server transfers, may make an FTP application layer gateway (ALG) >> go into transparent mode by issuing AUTH or ALGS commands as >> explained in Section 5. > >> I thought server-to-server transfer had been banned for many years now >> (it was exploited for address scan purposes). Am I missing something? > >Do you have a reference? > >As it's only listed here as an example of something that isn't addressed, >I don't think it's an issue to include this here. > >> * Section 5: >> In the second case, an implementation MUST have the ability to track >> and update TCP sequence numbers when translating packets as well as >> the ability to break up packets into smaller packets after >> [....] > >> What about the TCP URG flag and the Urgent Pointer? FTP is one of the >> few legacy applications that make use of TCP's urgent mode. And while >> use in new applications is deprecated, and TCP urgent mode itself is >> unreliable (see RFC 6093), you should make an explicit decision about >> what to do with TCP urgent mode when used for the FTP control channel. > >The word "urgent" isn't mentioned in RFC 959 or the FTP-related part of >RFC 1123. But RFC 959 does mention using the Telnet SYNCH signal, which >involves using urgent data. However, it looks like it's legal to ignore >the urgent pointer, from RFC 793: > > TCP also provides a means to communicate to the receiver of data that > at some point further along in the data stream than the receiver is > currently reading there is urgent data. TCP does not attempt to > define what the user specifically does upon being notified of pending > urgent data, but the general notion is that the receiving process will > take action to process the urgent data quickly > >> When packets are translated individually, the ALG should update the >> Urgent Pointer if/where necessary. If the ALG terminates the IPv6 TCP >> session, there's the question of whether urgent mode should be "copied" >> from the IPv6 session to the IPv4 session. > >I think it's not worth the trouble and unlikely to be tested well, so I >would be in favor of clearing the URG flag. Any objections? > >> * Section 5.1, page 7: >> For the time being, ALG implementations may employ >> one of the following strategies regarding LANG negotiation > >> Should you s/may/MAY/? > >Not really. I'll see what the RFC Editor says. > >> * Section 5.1, page 8: >> 3. Block LANG negotiation by translating the LANG command to a NOOP >> command, and translating the resulting 200 response into a >> response appropriate for unsupported commands, such as 500. Text >> is sent in the default language. > >> I think you should mandate which exact code the 200 should be translated >> to, rather than just provide an example. > >Let's make it a 502 then. > >> 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. > >> Remove the comma between "today" and "others" > >Ok. > >> translators >> are used to bridge that gap, FTP is made to work through these >> translators as best it can. > >> s/as best as it can/to the best possible extent/? > >Why not. > >> * Section 5.1 (page 7) and elsewhere: >> So the situation where the client and server try to >> negotiate a language that the ALG doesn't support can't be avoided. > >> Expand doesn't to "does not", "can't" to "cannot", etc. > >Hm, the 425 code has "can't" in it. I'll leave this open and see what the >RFC Editor says. > >> * Section 5.1, page 8: >> Note that [RFC2640] section 3.1 specifies new handling for spaces and >> the CR character in path names. > >> Rephrase to "Note that Section 3.1 of [RFC2640]..." > >I adopted the word order but not the capitalization. > >> * Section 11, page 12: >> ALGs MUST support the new ALGS (ALG status) command that allows >> command MUST be passed on to the server without modification, and the >> clients to query and set the ALG's status. > >> I had trouble parsing this sentence. > >This is the text that is in -10: > > ALGs MUST support the new ALGS (ALG status) command that allows > clients to query and set the ALG's status. FTP servers (as opposed > to ALGs) MUST NOT perform any actions upon receiving the ALGS > command. FTP servers MUST still send a response, however. > If FTP servers recognize the ALGS command, the best course > of action would be to return a 202 response: > >Apparently two lines got lost at your end. > >> * Section 11, page 12: >> A client can use the ALGS command to request the ALG's status and to >> enable and disable EPSV to PASV and, if implemented, EPRT to PORT >> translation. > >> Please rephrase to "...disable EPSV to PASV translation and, if >> implemented, EPRT to PORT translation". > >Ok. > >Both of you, thanks for the reviews. >_______________________________________________ >Behave mailing list >Behave@ietf.org >https://www.ietf.org/mailman/listinfo/behave From zhengyli@cisco.com Thu Jun 30 00:31:00 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 1ADEB21F869C; Thu, 30 Jun 2011 00:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.669 X-Spam-Level: X-Spam-Status: No, score=-8.669 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_62=0.6, 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 90meHGiTFoMH; Thu, 30 Jun 2011 00:30:58 -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 8BE0621F86A5; Thu, 30 Jun 2011 00:30:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=zhengyli@cisco.com; l=14669; q=dns/txt; s=iport; t=1309419056; x=1310628656; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=v9hbqJ5geZg2YJS11T/NN5K8MmfUPU5yoLqnpQnQ9GY=; b=CxjO915F/In6zwlGmOrQBQGbYseXc39tb0ptP/DPhTvu9rvKqTt71kSe Ryrf1l92EwgdS0CY5oceNhfEMR31kwX5L6mhT4QgsA4/BAMu9yEZ543y5 yaTJSlBr82XE7GZ6Oq3VinyD1zYGmCVYLIK9rJniHHytOBm7zIiCjipQQ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAPwkDE5Io8UR/2dsb2JhbABSp013qiqeDIYwBIc4imuEdYtD X-IronPort-AV: E=Sophos;i="4.65,449,1304294400"; d="scan'208";a="39960118" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-2.cisco.com with ESMTP; 30 Jun 2011 07:30:51 +0000 Received: from [64.104.167.59] ([64.104.167.59]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5U7UgBV014117; Thu, 30 Jun 2011 07:30:49 GMT User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Thu, 30 Jun 2011 15:30:41 +0800 From: Rockson Li To: Iljitsch van Beijnum , David Harrington Message-ID: Thread-Topic: [BEHAVE] FW: Last Call: (An FTP ALG for IPv6-to-IPv4 translation) to Proposed Standard In-Reply-To: <817780D4-1CF0-4A5A-90A8-E8BF98A2274F@muada.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: draft-ietf-behave-ftp64@tools.ietf.org, fgont@acm.org, "behave@ietf.orgWG WG" , Pekka Savola , TSV Area , "behave-chairs@tools.ietf.org Chairs" , TSV Dir , draft-ietf-behave-ftp64.all@tools.ietf.org, Fernando Gont Subject: Re: [BEHAVE] FW: Last Call: (An FTP ALG for IPv6-to-IPv4 translation) to Proposed Standard 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, 30 Jun 2011 07:31:00 -0000 |The document does not mention or discuss LPRT and LPSV. Is that intentional? |The IANA registry says these are now obsolete, but RFC1639 is still |experimental and no document has (formally) obsoleted these. [RL] It looks like sec 2.5 of RFC5797 has obsoleted those two commands. On ".. is it? I thought the source port used by the server is orthogonal to whether pasv/port is issued. AFAIK, multiple FTP server implementations never use port 20. But I have not recently tested this myself. " I think David was asking,do we need to assume the source port 20 from ftp server for data connection would be always true if On 6/28/11 12:17 AM, "Iljitsch van Beijnum" wrote: >FTP ALG implementers: please respond if you have an opinion, some stuff >below may make your life harder! (This is a response to two different >messages.) > >On 3 jun 2011, at 14:06, David Harrington wrote: > >> Can you address these issues? >> Do you have any other comments you know of that need to be included in >> a new rev? > >There were three reviews. See below for two, I'm trying to clear >something up about the other more directly. > >On 30 mei 2011, at 11:10, Pekka Savola wrote: > >> This is an ops-dir review of draft-ietf-behave-ftp64-10. > >> substantial comments >> -------------------- > >> The document does not mention or discuss LPRT and LPSV. Is that >>intentional? >> The IANA registry says these are now obsolete, but RFC1639 is still >> experimental and no document has (formally) obsoleted these. > >I managed to overlook RFC 1639, and it wasn't brought up by anyone else >during the process. Apparently wu-ftpd implements this and curl used to, >but both failed to see any real-world usage so I think we can ignore this >without creating problems. > >> Telnet option negotiation attempts by either the client or the >> server, except for those allowed by [RFC1123], MUST be rejected by >> the FTP ALG without relaying those attempts. This avoids the >> situation where the client and the server negotiate Telnet options >> that are unimplemented by the FTP ALG. > >> ... what does "rejected" mean exactly? Does the ALG send back to >> the negotiation attempter some error code? Does it abort the >>connection? >> ignore these options? strip them out when connecting to the other end? > >What I had in mind was reply with a "DON'T". Is this text more clear? > > Telnet option negotiation attempts by either the client or the > server, except for those allowed by [RFC1123], MUST be rejected by > the FTP ALG without relaying those attempts. For the purpose of > Telnet option negotiation, an FTP ALG MUST follow the behavior of > an FTP server as specified in [RFC1123] section 4.1.2.12. This... > >That section says: > > 4.1.2.12 Connections: RFC-959 Section 5.2 > > The words "and the port used" in the second paragraph of > this section of RFC-959 are erroneous (historical), and they > should be ignored. > > On a multihomed server host, the default data transfer port > (L-1) MUST be associated with the same local IP address as > the corresponding control connection to port L. > > A user-FTP MUST NOT send any Telnet controls other than > SYNCH and IP on an FTP control connection. In particular, it > MUST NOT attempt to negotiate Telnet options on the control > connection. However, a server-FTP MUST be capable of > accepting and refusing Telnet negotiations (i.e., sending > DONT/WONT). > > DISCUSSION: > Although the RFC says: "Server- and User- processes > should follow the conventions for the Telnet > protocol...[on the control connection]", it is not the > intent that Telnet option negotiation is to be > employed. > >> 8. Default port 20 translation > >> If the client does not issue an EPSV/PASV or EPRT/PORT command prior >> to initiating a file transfer, it is invoking the default active FTP >> behavior where the server sets up a TCP session towards the client. >> In this situation, the source port number is the default FTP data >> port (port 20) and the destination port is the port the client uses >> as the source port for the control channel session. > >> .. is it? I thought the source port used by the server is orthogonal to >> whether pasv/port is issued. AFAIK, multiple FTP server implementations >> never use port 20. But I have not recently tested this myself. > >RFC 959: > > 3.2. ESTABLISHING DATA CONNECTIONS > > The mechanics of transferring data consists of setting up the data > connection to the appropriate ports and choosing the parameters > for transfer. Both the user and the server-DTPs have a default > data port. The user-process default data port is the same as the > control connection port (i.e., U). The server-process default > data port is the port adjacent to the control connection port > (i.e., L-1). > >> The ALG MUST enable or disable EPSV to PASV translation as requested. >> If EPRT to PORT translation is supported, ALGS ENABLE64 SHOULD enable >> it and ALGS DISABLE64 SHOULD disable it along with enabling or >> disabling EPSV to PASV translation, respectively. If EPRT to PORT >> translation is not supported, ALGS ENABLE64 only enables EPSV to PASV >> translation. > >> .. what does this SHOULD..along with.. mean? I read it so that it's OK >> that for "ALGS DISABLE64" EPSV->PASV is disabled but EPRT->PORT is not >> disabled? A different way to read it would be that both EPSV->PASV and >> EPRT->PORT are SHOULDs. > >I think what it says is that it's optional to disable PORT->EPRT upon >DISABLE64. Enabling is optional because the feature is optional, but I >guess if you have the feature disabling should be mandatory, so >SHOULD->MUST: > > The ALG MUST enable or disable EPSV to PASV translation as requested. > If EPRT to PORT translation is supported, ALGS ENABLE64 MUST enable > it and ALGS DISABLE64 MUST disable it along with... > >Agree? > >> A survey done in April of 2009 of 25 randomly picked and/or well- >> known FTP sites reachable over IPv4 showed that only 12 of them >> supported EPSV over IPv4. > >> .. fwiw, Dan Wing redid this test on 18 May 2011, reporting on behave >>list. >> the results didn't differ much (I didn't look at the numbers), but if >>you >> want to update this, now would be the chance. > >I don't see the need to. > >> If >> such a multi-purpose ALG forbids the use of the AUTH command for >> policy reasons, the side effect of making the ALG stop performing the >> translations described here, as well as other possible interventions >> related to IPv6-to-IPv4 translation, MUST be retained even if the ALG >> responds to the AUTH command with an error and does not propagate the >> command to the server. > >> .. I had a hard time following what this one sentence includign a MUST >> actually requires. Maybe break down to more easily digestible >>sentences? > >What about this: > >If such a multi-purpose ALG forbids the use of the AUTH command for >policy reasons, the side effect of the AUTH command as described in this >document MUST be retained. In other words, if the ALG does not propagate >the AUTH command to the server, the ALG MUST still stop all possible >interventions related to IPv6-to-IPv4 translation. This is true for the >remaining duration >of the control channel session, and applies even if the ALG >responds to the AUTH command with an error. > >> [Bernstein] >> Bernstein, D., "PASV security and PORT security", 2000, >> . > >> .. this reference is not cited in the doc, add or remove? > >I'll remove it. > > >On 4 jun 2011, at 0:16, Fernando Gont wrote: > >> I've reviewed this document as part of the transport area directorate's >> ongoing effort to review key IETF documents. > > >> * Section 1, page 3: >> In 5 cases, issuing the EPSV >> command to the server led to a significant delay, in 3 cases followed >> by a control channel reset. > >> Could you please clarify what was the cause of the delay? And, btw, have >> you guys put the details of your results publicly available somewhere? > >What about the following text: > >Due to lack of additional information, it is impossible to determine >conclusively why certain FTP servers reset the control channel connection >some time after issueing an EPSV command. However, a reasonable >explanation would be that these FTP servers are located behind >application-aware firewalls which monitor the control channel session and >only allow the creation of data channel sessions to the ports listed in >the responses to PASV (and maybe PORT) commands. As the response to an >EPSV command is different (a 229 code rather than a 227 code), a firewall >that is unaware of the EPSV command would block the subsequent data >channel setup attempt, after which the FTP server may decide to terminate >the control channel session which isn't progressing the way it should. > >> * Section 1, page 3-4: >> Clients that want to engage in more complex behavior, such as server- >> to-server transfers, may make an FTP application layer gateway (ALG) >> go into transparent mode by issuing AUTH or ALGS commands as >> explained in Section 5. > >> I thought server-to-server transfer had been banned for many years now >> (it was exploited for address scan purposes). Am I missing something? > >Do you have a reference? > >As it's only listed here as an example of something that isn't addressed, >I don't think it's an issue to include this here. > >> * Section 5: >> In the second case, an implementation MUST have the ability to track >> and update TCP sequence numbers when translating packets as well as >> the ability to break up packets into smaller packets after >> [....] > >> What about the TCP URG flag and the Urgent Pointer? FTP is one of the >> few legacy applications that make use of TCP's urgent mode. And while >> use in new applications is deprecated, and TCP urgent mode itself is >> unreliable (see RFC 6093), you should make an explicit decision about >> what to do with TCP urgent mode when used for the FTP control channel. > >The word "urgent" isn't mentioned in RFC 959 or the FTP-related part of >RFC 1123. But RFC 959 does mention using the Telnet SYNCH signal, which >involves using urgent data. However, it looks like it's legal to ignore >the urgent pointer, from RFC 793: > > TCP also provides a means to communicate to the receiver of data that > at some point further along in the data stream than the receiver is > currently reading there is urgent data. TCP does not attempt to > define what the user specifically does upon being notified of pending > urgent data, but the general notion is that the receiving process will > take action to process the urgent data quickly > >> When packets are translated individually, the ALG should update the >> Urgent Pointer if/where necessary. If the ALG terminates the IPv6 TCP >> session, there's the question of whether urgent mode should be "copied" >> from the IPv6 session to the IPv4 session. > >I think it's not worth the trouble and unlikely to be tested well, so I >would be in favor of clearing the URG flag. Any objections? > >> * Section 5.1, page 7: >> For the time being, ALG implementations may employ >> one of the following strategies regarding LANG negotiation > >> Should you s/may/MAY/? > >Not really. I'll see what the RFC Editor says. > >> * Section 5.1, page 8: >> 3. Block LANG negotiation by translating the LANG command to a NOOP >> command, and translating the resulting 200 response into a >> response appropriate for unsupported commands, such as 500. Text >> is sent in the default language. > >> I think you should mandate which exact code the 200 should be translated >> to, rather than just provide an example. > >Let's make it a 502 then. > >> 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. > >> Remove the comma between "today" and "others" > >Ok. > >> translators >> are used to bridge that gap, FTP is made to work through these >> translators as best it can. > >> s/as best as it can/to the best possible extent/? > >Why not. > >> * Section 5.1 (page 7) and elsewhere: >> So the situation where the client and server try to >> negotiate a language that the ALG doesn't support can't be avoided. > >> Expand doesn't to "does not", "can't" to "cannot", etc. > >Hm, the 425 code has "can't" in it. I'll leave this open and see what the >RFC Editor says. > >> * Section 5.1, page 8: >> Note that [RFC2640] section 3.1 specifies new handling for spaces and >> the CR character in path names. > >> Rephrase to "Note that Section 3.1 of [RFC2640]..." > >I adopted the word order but not the capitalization. > >> * Section 11, page 12: >> ALGs MUST support the new ALGS (ALG status) command that allows >> command MUST be passed on to the server without modification, and the >> clients to query and set the ALG's status. > >> I had trouble parsing this sentence. > >This is the text that is in -10: > > ALGs MUST support the new ALGS (ALG status) command that allows > clients to query and set the ALG's status. FTP servers (as opposed > to ALGs) MUST NOT perform any actions upon receiving the ALGS > command. FTP servers MUST still send a response, however. > If FTP servers recognize the ALGS command, the best course > of action would be to return a 202 response: > >Apparently two lines got lost at your end. > >> * Section 11, page 12: >> A client can use the ALGS command to request the ALG's status and to >> enable and disable EPSV to PASV and, if implemented, EPRT to PORT >> translation. > >> Please rephrase to "...disable EPSV to PASV translation and, if >> implemented, EPRT to PORT translation". > >Ok. > >Both of you, thanks for the reviews. >_______________________________________________ >Behave mailing list >Behave@ietf.org >https://www.ietf.org/mailman/listinfo/behave From zhengyli@cisco.com Thu Jun 30 02:50: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 EB9CA21F87EA for ; Thu, 30 Jun 2011 02:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.819 X-Spam-Level: X-Spam-Status: No, score=-8.819 tagged_above=-999 required=5 tests=[AWL=0.150, 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 AcpjivP2E7Dk for ; Thu, 30 Jun 2011 02:50:07 -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 3CFE621F87E2 for ; Thu, 30 Jun 2011 02:50:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=zhengyli@cisco.com; l=1642; q=dns/txt; s=iport; t=1309427407; x=1310637007; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=UFqnGapiEkOxSCH/yeoI9zy3+QR+ZbaJiNghRagSwlc=; b=JmyoGVVbYC1nEoTN0fkEyPWTp+ZJRGdMKcO+pFefaFMwxz3onuZocpRW gY8+TMyyX2DI2cfg47lgIvwWqSBJs4gk4rP036RFrrUR9dpLUc2z0WfFU UGUZ4TOFQyExvURAyw+c3EWEuhlT62/7QBAYd+ZDG1zaiNsFKMlRUT2tE I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EALVFDE5Io8UR/2dsb2JhbABSp1N3qimeFIYxBIc+inGEdotF X-IronPort-AV: E=Sophos;i="4.65,449,1304294400"; d="scan'208";a="39987331" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-2.cisco.com with ESMTP; 30 Jun 2011 09:50:05 +0000 Received: from [64.104.167.59] ([64.104.167.59]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5U9o2k1006061; Thu, 30 Jun 2011 09:50:03 GMT User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Thu, 30 Jun 2011 17:50:00 +0800 From: Rockson Li To: Iljitsch van Beijnum Message-ID: Thread-Topic: question on draft-ietf-behave-ftp64-10.txt In-Reply-To: <0A90C41B-67D1-48F4-801F-8A08EA103335@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] question on draft-ietf-behave-ftp64-10.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, 30 Jun 2011 09:50:08 -0000 Iljitsch, I have some questions on draft-ietf-behave-ftp64-10. Can you help to address them please? Thanks Regards, -Rockson sec 5 An ALG MUST adopt the first option, and allow a client and a server to negotiate security mechanisms. 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. This applies even if the AUTH command is unsuccessful. [RL] if the server cannot support the security extention client proposed and retur a failure response, why ALG needs to continue work in transparent mode? sec 7.1 If the address specified in the EPRT command is an IPv4 address or an IPv6 address that is not the IPv6 address used by the client for the control session, the ALG SHOULD NOT attempt any translation, but pass along the command unchanged. [RL] FTP allow a control sessions to establish a data connection for two remote hosts. Why ALG should not attempt to do the translation if different IPv6 address used by the client for the control session, sec 12 Whenever a command from the client is not propagated to the server, the FTP ALG instead issues a NOOP command in order to keep the keepalive state between the client and the server synchronized [RL] I don't quite understand the point here, why we need NOOP to synchronize client and server? if ALG choose to reponds the request itself, why server care about NOOP here? From fernando.gont.netbook.win@gmail.com Thu Jun 30 03:19: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 52B8E21F8808; Thu, 30 Jun 2011 03:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.389 X-Spam-Level: X-Spam-Status: No, score=-3.389 tagged_above=-999 required=5 tests=[AWL=0.210, 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 DJXwv1vsDaHX; Thu, 30 Jun 2011 03:19:36 -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 0876E21F87DE; Thu, 30 Jun 2011 03:19:35 -0700 (PDT) Received: by yie30 with SMTP id 30so1045081yie.31 for ; Thu, 30 Jun 2011 03:19:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=jeBmZPmDSWs4TyAsbgE5KEqdLNm4rUakEMVQpKybk74=; b=dZzj41JS1BONi9XmFGmBX0MdFgRKm38c66gTmkmdMZGNpx80q9aaCY0bgbZ56u7W+x 3CY8cULm52jO9tWfBkkofxj17QflwZ3s/uUpbXXgVvMOmM8MjMfv0mCmwuFCysCgS18t GHXr6pzVMQ2hWWt13KgK4uRI8Fkh8LCJc57oI= Received: by 10.91.72.1 with SMTP id z1mr1665609agk.78.1309429170000; Thu, 30 Jun 2011 03:19:30 -0700 (PDT) Received: from [192.168.123.103] ([190.48.255.131]) by mx.google.com with ESMTPS id v16sm1873809ann.39.2011.06.30.03.19.20 (version=SSLv3 cipher=OTHER); Thu, 30 Jun 2011 03:19:28 -0700 (PDT) Sender: Fernando Gont Message-ID: <4E0C4DA5.5000005@gont.com.ar> Date: Thu, 30 Jun 2011 07:19:17 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: Iljitsch van Beijnum References: <04C1AFDBEA554F3FA5FDD978C1682D6E@davidPC> <817780D4-1CF0-4A5A-90A8-E8BF98A2274F@muada.com> In-Reply-To: <817780D4-1CF0-4A5A-90A8-E8BF98A2274F@muada.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: draft-ietf-behave-ftp64@tools.ietf.org, fgont@acm.org, "behave@ietf.orgWG WG" , Pekka Savola , TSV Area , "behave-chairs@tools.ietf.org Chairs" , TSV Dir , draft-ietf-behave-ftp64.all@tools.ietf.org, David Harrington Subject: Re: [BEHAVE] FW: Last Call: (An FTP ALG for IPv6-to-IPv4 translation) to Proposed Standard 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, 30 Jun 2011 10:19:37 -0000 Hi, Iljitsch, [I'm responding only to those parts that correspond to my tsv-dir review] On 06/27/2011 01:17 PM, Iljitsch van Beijnum wrote: > On 4 jun 2011, at 0:16, Fernando Gont wrote: > >> I've reviewed this document as part of the transport area >> directorate's ongoing effort to review key IETF documents. > >> * Section 1, page 3: In 5 cases, issuing the EPSV command to the >> server led to a significant delay, in 3 cases followed by a control >> channel reset. > >> Could you please clarify what was the cause of the delay? And, btw, >> have you guys put the details of your results publicly available >> somewhere? > > What about the following text: > > Due to lack of additional information, it is impossible to determine > conclusively why certain FTP servers reset the control channel > connection some time after issueing an EPSV command. However, a > reasonable explanation would be that these FTP servers are located > behind application-aware firewalls which monitor the control channel > session and only allow the creation of data channel sessions to the > ports listed in the responses to PASV (and maybe PORT) commands. As > the response to an EPSV command is different (a 229 code rather than > a 227 code), a firewall that is unaware of the EPSV command would > block the subsequent data channel setup attempt, after which the FTP > server may decide to terminate the control channel session which > isn't progressing the way it should. Works for me. :-) -- If you have an external document with more data about this experiment, it might eb good to provide a link to it. >> * Section 1, page 3-4: Clients that want to engage in more complex >> behavior, such as server- to-server transfers, may make an FTP >> application layer gateway (ALG) go into transparent mode by issuing >> AUTH or ALGS commands as explained in Section 5. > >> I thought server-to-server transfer had been banned for many years >> now (it was exploited for address scan purposes). Am I missing >> something? > > Do you have a reference? * http://nmap.org/hobbit.ftpbounce.txt * http://www.cert.org/advisories/CA-1997-27.html * http://cr.yp.to/ftp/security.html * IETF RFC 2577 > As it's only listed here as an example of something that isn't > addressed, I don't think it's an issue to include this here. The point is that proxy FTP is not supporting in the FTP software I checked. >> * Section 5: In the second case, an implementation MUST have the >> ability to track and update TCP sequence numbers when translating >> packets as well as the ability to break up packets into smaller >> packets after [....] > >> What about the TCP URG flag and the Urgent Pointer? FTP is one of >> the few legacy applications that make use of TCP's urgent mode. And >> while use in new applications is deprecated, and TCP urgent mode >> itself is unreliable (see RFC 6093), you should make an explicit >> decision about what to do with TCP urgent mode when used for the >> FTP control channel. > > The word "urgent" isn't mentioned in RFC 959 or the FTP-related part > of RFC 1123. But RFC 959 does mention using the Telnet SYNCH signal, > which involves using urgent data. However, it looks like it's legal > to ignore the urgent pointer, from RFC 793: > > TCP also provides a means to communicate to the receiver of data > that at some point further along in the data stream than the receiver > is currently reading there is urgent data. TCP does not attempt to > define what the user specifically does upon being notified of > pending urgent data, but the general notion is that the receiving > process will take action to process the urgent data quickly Well, *TCP* does not state what should be done with the urgent data, since it doesn't know what's the application on top. But if you ignore urgent indications, you won't be able to interrupt ongoing commands (e.g. RETR). -- so my take is that this is important for FTP. Unfortunately, as noted in RFC6093, some middleboxes already play with urgent indications. BUt if you deliberatly ignore it, this would exacerbate the problem. >> When packets are translated individually, the ALG should update >> the Urgent Pointer if/where necessary. If the ALG terminates the >> IPv6 TCP session, there's the question of whether urgent mode >> should be "copied" from the IPv6 session to the IPv4 session. > > I think it's not worth the trouble and unlikely to be tested well, so > I would be in favor of clearing the URG flag. Any objections? My understanding is that the implications of this is that you no longer will be able to abort commands (head of line blocking). >> * Section 5.1 (page 7) and elsewhere: So the situation where the >> client and server try to negotiate a language that the ALG doesn't >> support can't be avoided. > >> Expand doesn't to "does not", "can't" to "cannot", etc. > > Hm, the 425 code has "can't" in it. I'll leave this open and see what > the RFC Editor says. Ok... I thought it was the wording of your explanation (RFC-Ed seems to prefer "can't" -> cannot "you're" -> "you are", etc.) (FWIW, I've omitted responses to comments that you've already addresses and that needed no further discussion). Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From lizhenqiang@chinamobile.com Thu Jun 30 04:10:48 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 4F77921F862F for ; Thu, 30 Jun 2011 04:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.977 X-Spam-Level: *** X-Spam-Status: No, score=3.977 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RELAY_IS_221=2.222] 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 bUYpp5NDO5Zk for ; Thu, 30 Jun 2011 04:10:43 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id EEA0621F86BF for ; Thu, 30 Jun 2011 04:10:42 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 364E3A6DB for ; Thu, 30 Jun 2011 19:10:31 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 15DB5A6BE for ; Thu, 30 Jun 2011 19:10:31 +0800 (CST) Received: from lizhengqiang ([10.2.2.206]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2011063019102484-19039 ; Thu, 30 Jun 2011 19:10:24 +0800 Date: Thu, 30 Jun 2011 19:10:21 +0800 From: "lizhenqiang" To: behave@ietf.org References: Message-ID: <201106301910209453764@chinamobile.com> X-mailer: Foxmail 6, 9, 201, 16 [cn] Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-06-30 19:10:24, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-06-30 19:10:30, Serialize complete at 2011-06-30 19:10:30 Content-Type: multipart/alternative; boundary="=====003_Dragon374535001856_=====" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18230.005 X-TM-AS-Result: No-0.169-7.0-31-10 X-imss-scan-details: No-0.169-7.0-31-10;No-0.169-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No Subject: [BEHAVE] What is the purpose to consider the non-standard IPv6 address 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: Thu, 30 Jun 2011 11:10:48 -0000 This is a multi-part message in MIME format. --=====003_Dragon374535001856_===== Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="gb2312" Hello Everyone, Setion 3.2 of draft-ietf-behave-nat64-discovery-heuristic-01 considers non-standard IPv6 address formats. I want to know the purpose. This condition violates what is described in RFC6052.Why not treat this condition as error? Even after performing more complex heuristics, a node finds the IPv4 address for the WKN, the node is difficult to decide the NSP from the returned IPv6 address. Best Regards, Zhenqiang Li 2011-06-30 --=====003_Dragon374535001856_===== Content-Transfer-Encoding: base64 Content-Type: text/html; charset="gb2312" PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBuYW1lPUdFTkVSQVRPUiBjb250 ZW50PSJNU0hUTUwgOC4wMC43NjAwLjE2ODIxIj4NCjxTVFlMRT5AZm9udC1mYWNlIHsNCglmb250 LWZhbWlseTogy87M5TsNCn0NCkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBWZXJkYW5hOw0K fQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IEDLzszlOw0KfQ0KQHBhZ2UgU2VjdGlvbjEg e3NpemU6IDU5NS4zcHQgODQxLjlwdDsgbWFyZ2luOiA3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4w cHQ7IGxheW91dC1ncmlkOiAxNS42cHQ7IH0NClAuTXNvTm9ybWFsIHsNCglURVhULUpVU1RJRlk6 IGludGVyLWlkZW9ncmFwaDsgVEVYVC1BTElHTjoganVzdGlmeTsgTUFSR0lOOiAwY20gMGNtIDBw dDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iOyBGT05ULVNJWkU6IDEwLjVwdA0KfQ0K TEkuTXNvTm9ybWFsIHsNCglURVhULUpVU1RJRlk6IGludGVyLWlkZW9ncmFwaDsgVEVYVC1BTElH TjoganVzdGlmeTsgTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcg Um9tYW4iOyBGT05ULVNJWkU6IDEwLjVwdA0KfQ0KRElWLk1zb05vcm1hbCB7DQoJVEVYVC1KVVNU SUZZOiBpbnRlci1pZGVvZ3JhcGg7IFRFWFQtQUxJR046IGp1c3RpZnk7IE1BUkdJTjogMGNtIDBj bSAwcHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgRk9OVC1TSVpFOiAxMC41cHQN Cn0NCkE6bGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lDQp9 DQpTUEFOLk1zb0h5cGVybGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5k ZXJsaW5lDQp9DQpBOnZpc2l0ZWQgew0KCUNPTE9SOiBwdXJwbGU7IFRFWFQtREVDT1JBVElPTjog dW5kZXJsaW5lDQp9DQpTUEFOLk1zb0h5cGVybGlua0ZvbGxvd2VkIHsNCglDT0xPUjogcHVycGxl OyBURVhULURFQ09SQVRJT046IHVuZGVybGluZQ0KfQ0KU1BBTi5FbWFpbFN0eWxlMTcgew0KCUZP TlQtU1RZTEU6IG5vcm1hbDsgRk9OVC1GQU1JTFk6IFZlcmRhbmE7IENPTE9SOiB3aW5kb3d0ZXh0 OyBGT05ULVdFSUdIVDogbm9ybWFsOyBURVhULURFQ09SQVRJT046IG5vbmU7IG1zby1zdHlsZS10 eXBlOiBwZXJzb25hbC1jb21wb3NlDQp9DQpESVYuU2VjdGlvbjEgew0KCXBhZ2U6IFNlY3Rpb24x DQp9DQpVTktOT1dOIHsNCglGT05ULVNJWkU6IDEwcHQNCn0NCkJMT0NLUVVPVEUgew0KCU1BUkdJ Ti1UT1A6IDBweDsgTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tTEVGVDogMmVtDQp9DQpPTCB7 DQoJTUFSR0lOLVRPUDogMHB4OyBNQVJHSU4tQk9UVE9NOiAwcHgNCn0NClVMIHsNCglNQVJHSU4t VE9QOiAwcHg7IE1BUkdJTi1CT1RUT006IDBweA0KfQ0KPC9TVFlMRT4NCjwvSEVBRD4NCjxCT0RZ IHN0eWxlPSJGT05ULUZBTUlMWTogdmVyZGFuYTsgRk9OVC1TSVpFOiAxMHB0Ij4NCjxESVY+PEZP TlQgY29sb3I9IzAwMDA4MCBzaXplPTIgZmFjZT1WZXJkYW5hPkhlbGxvIEV2ZXJ5b25lLDwvRk9O VD48L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDA4MD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8 RElWPjxGT05UIGNvbG9yPSMwMDAwODA+U2V0aW9uIDMuMiBvZiANCmRyYWZ0LWlldGYtYmVoYXZl LW5hdDY0LWRpc2NvdmVyeS1oZXVyaXN0aWMtMDEgY29uc2lkZXJzIG5vbi1zdGFuZGFyZCBJUHY2 IA0KYWRkcmVzcyBmb3JtYXRzLiBJIHdhbnQgdG8ga25vdyB0aGUgcHVycG9zZS4gVGhpcyBjb25k aXRpb24gdmlvbGF0ZXMgd2hhdCBpcyANCmRlc2NyaWJlZCBpbiBSRkM2MDUyLldoeSBub3QgdHJl YXQgdGhpcyBjb25kaXRpb24gYXMgZXJyb3I/IEV2ZW4gYWZ0ZXIgDQpwZXJmb3JtaW5nIG1vcmUg Y29tcGxleCBoZXVyaXN0aWNzLCBhIG5vZGUgZmluZHMgdGhlIElQdjQgYWRkcmVzcyBmb3IgdGhl IA0KV0tOLCZuYnNwO3RoZSBub2RlIGlzIGRpZmZpY3VsdCB0byZuYnNwO2RlY2lkZSB0aGUmbmJz cDtOU1AmbmJzcDtmcm9tIHRoZSANCnJldHVybmVkIElQdjYgYWRkcmVzcy48L0ZPTlQ+PC9ESVY+ DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwODA+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9O VCBjb2xvcj0jMDAwMDgwPkJlc3QgUmVnYXJkcyw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGNv bG9yPSMwMDAwODA+WmhlbnFpYW5nIExpPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0j MDAwMDgwPjIwMTEtMDYtMzAmbmJzcDsmbmJzcDs8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGNv bG9yPSMwMDAwODAgc2l6ZT0yIGZhY2U9VmVyZGFuYT48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElW PjxGT05UIGNvbG9yPSMwMDAwODAgc2l6ZT0yIGZhY2U9VmVyZGFuYT48L0ZPTlQ+Jm5ic3A7PC9E SVY+PC9CT0RZPjwvSFRNTD4NCg== --=====003_Dragon374535001856_=====-- From lizhenqiang@chinamobile.com Thu Jun 30 04:16: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 454C121F87EA for ; Thu, 30 Jun 2011 04:16:58 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: 1.8 X-Spam-Level: * X-Spam-Status: No, score=1.8 tagged_above=-999 required=5 tests=[AWL=2.177, BAYES_00=-2.599, RELAY_IS_221=2.222] 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 EYSBEIepOokq for ; Thu, 30 Jun 2011 04:16:57 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 58E0821F87DF for ; Thu, 30 Jun 2011 04:16:57 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id EEEB5A6E7 for ; Thu, 30 Jun 2011 19:16:45 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id E78CBA6E4 for ; Thu, 30 Jun 2011 19:16:45 +0800 (CST) To: behave@ietf.org MIME-Version: 1.0 From: lizhenqiang@chinamobile.com Date: Thu, 30 Jun 2011 19:16:34 +0800 Message-ID: X-Mailer: Lotus Domino Web Server Release 6.5.6 March 06, 2007 X-MIMETrack: Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-06-30 19:16:45 MIME-Version: 1.0 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18230.005 X-TM-AS-Result: No-0.126-7.0-31-10 X-imss-scan-details: No-0.126-7.0-31-10;No-0.126-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No Subject: [BEHAVE] What is the purpose to consider the non-standard IPv6 address 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: Thu, 30 Jun 2011 11:16:58 -0000 Hello Everyone, Setion 3.2 of draft-ietf-behave-nat64-discovery-heuristic-01 considers non-= standard IPv6 address formats. I want to know the purpose. This condition v= iolates what is described in RFC6052.Why not treat this condition as error?= Even after performing more complex heuristics, a node finds the IPv4 addre= ss for the WKN, the node is difficult to decide the NSP from the returned I= Pv6 address. Best Regards, Zhenqiang Li 2011-06-30 = From iljitsch@muada.com Thu Jun 30 04:29:25 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 5A60421F8810 for ; Thu, 30 Jun 2011 04:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.513 X-Spam-Level: X-Spam-Status: No, score=-101.513 tagged_above=-999 required=5 tests=[AWL=-0.543, 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 W3kGBNjUkkX5 for ; Thu, 30 Jun 2011 04:29:25 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id AFC1221F87EF for ; Thu, 30 Jun 2011 04:29:24 -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 p5UBTuJB011148 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 30 Jun 2011 13:29:56 +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, 30 Jun 2011 13:29:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Rockson Li X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-behave-ftp64.all@tools.ietf.org, behave@ietf.org Subject: Re: [BEHAVE] question on draft-ietf-behave-ftp64-10.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, 30 Jun 2011 11:29:25 -0000 On 30 jun 2011, at 11:50, Rockson Li wrote: >> An ALG MUST adopt the first option, and allow a client and a server >> to negotiate security mechanisms. 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. >> This applies even if the AUTH command is unsuccessful. > [RL] if the server cannot support the security extention client = proposed > and retur a=20 > failure response, why ALG needs to continue work in transparent = mode? Because this way, if the client issues AUTH it knows the server went = into transparent mode. 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? >> If the address specified in the EPRT command is an IPv4 address or = an >> IPv6 address that is not the IPv6 address used by the client for = the >> control session, the ALG SHOULD NOT attempt any translation, but = pass >> along the command unchanged. > [RL] FTP allow a control sessions to establish a data connection for = two > remote hosts. > Why ALG should not attempt to do the translation if different IPv6 > address used by the client for the > control session, In that case, the client is almost certainly trying to do a = server-to-server transfer, a specification that allows for this would be = long and complex and very likely still not cover all possible cases. I = think there was some attempt to do this in an earlier version, but I = can't find it right now (there have been 18 versions of the draft so = far...). And see Fernando's messages, this is no longer a widely = supported mode of operation for FTP. So if people want to do this they'll have to calculate the right IPv6 = addresses themselves. >> Whenever a command from the client is not propagated to the server, >> the FTP ALG instead issues a NOOP command in order to keep the >> keepalive state between the client and the server synchronized > [RL] I don't quite understand the point here, why we need NOOP to > synchronize=20 > client and server? if ALG choose to reponds the request itself, = why > server > care about NOOP here? A client may track how long ago it last sent a command to the server and = issue a NOOP to avoid a timeout. If a command from the client never = reaches the server this strategy no longer works. So the requirement = above makes sure that whenever the client issues a command, the server = receives a command, even if it's just a NOOP. Iljitsch= From iljitsch@muada.com Thu Jun 30 05:37: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 C204211E8096; Thu, 30 Jun 2011 05:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.193 X-Spam-Level: X-Spam-Status: No, score=-102.193 tagged_above=-999 required=5 tests=[AWL=0.408, 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 ZpqUvG6Bhlis; Thu, 30 Jun 2011 05:37:22 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id 022FA9E8012; Thu, 30 Jun 2011 05:37:21 -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 p5UCbiuO011497 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 30 Jun 2011 14:37: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: <4E0C4DA5.5000005@gont.com.ar> Date: Thu, 30 Jun 2011 14:37:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <58D5D2BB-1E76-4E54-8C9B-054D84067BA8@muada.com> References: <04C1AFDBEA554F3FA5FDD978C1682D6E@davidPC> <817780D4-1CF0-4A5A-90A8-E8BF98A2274F@muada.com> <4E0C4DA5.5000005@gont.com.ar> To: Fernando Gont X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-behave-ftp64@tools.ietf.org, fgont@acm.org, "behave@ietf.orgWG WG" , Pekka Savola , TSV Area , "behave-chairs@tools.ietf.org Chairs" , TSV Dir , draft-ietf-behave-ftp64.all@tools.ietf.org, David Harrington Subject: Re: [BEHAVE] FW: Last Call: (An FTP ALG for IPv6-to-IPv4 translation) to Proposed Standard 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, 30 Jun 2011 12:37:23 -0000 On 30 jun 2011, at 12:19, Fernando Gont wrote: >>> I thought server-to-server transfer had been banned for many years >>> now (it was exploited for address scan purposes). Am I missing >>> something? >> Do you have a reference? > * http://nmap.org/hobbit.ftpbounce.txt > * http://www.cert.org/advisories/CA-1997-27.html > * http://cr.yp.to/ftp/security.html I don't think these three are useful as they fall outside the scope of = the IETF. > * IETF RFC 2577 I think this is the relevant part: Disabling the PORT command is also an option for protecting against the bounce attack. Most file transfers can be made using only the PASV command [Bel94]. The disadvantage of disabling the PORT command is that one loses the ability to use proxy FTP, but proxy FTP may not be necessary in a particular environment. This doesn't forbid or deprecate server-to-server transfers. >> As it's only listed here as an example of something that isn't >> addressed, I don't think it's an issue to include this here. > The point is that proxy FTP is not supporting in the FTP software I = checked. FTP predates TCP/IP but I doubt many implementations can still run over = NCP... Unfortunately there is no single FTP spec that lists only those things = still in active use. In fact, earlier this week I found out that wu-ftpd = still supports RFC 1639 long addresses, which is an experimental spec to = support non-32-bit addresses before IPv6 was standardized. And being good students of Jon Postel, we are conservative in what we = send and liberal in what we accept. [urgent data] > Well, *TCP* does not state what should be done with the urgent data, > since it doesn't know what's the application on top. But if you ignore > urgent indications, you won't be able to interrupt ongoing commands > (e.g. RETR). -- so my take is that this is important for FTP. > Unfortunately, as noted in RFC6093, some middleboxes already play with > urgent indications. BUt if you deliberatly ignore it, this would > exacerbate the problem. I tried interrupting a transfer, and my client (the MacOS commandline = one) did indeed send a packet with urgent data to ftp.nluug.nl but the = transfer didn't get aborted so apparently it may be unreliable either = way. So I want to add this text: Some FTP clients use the TCP urgent data feature when interrupting = transfers. An ALG MUST either maintain the semantics of the urgent = pointer when translating control channel interactions, even when = crossing packet boundaries, or clear the URG bit in the TCP header. >> I think it's not worth the trouble and unlikely to be tested well, so >> I would be in favor of clearing the URG flag. Any objections? > My understanding is that the implications of this is that you no = longer > will be able to abort commands (head of line blocking). Hm, doesn't this only apply to the situation where command 1 is being = executed, command 2 has been given but is waiting to be executed and = command 3 is ABOR? The urgent pointer allows the server to look at the = ABOR even though command 2 is earlier in the pipeline. But if there is = no command 2 it shouldn't matter.= From internet-drafts@ietf.org Thu Jun 30 06:31: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 9DE4F11E8115; Thu, 30 Jun 2011 06:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 Ooiv7-cjaHDm; Thu, 30 Jun 2011 06:31:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 301D311E80E0; Thu, 30 Jun 2011 06:31:39 -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: <20110630133139.30337.46929.idtracker@ietfa.amsl.com> Date: Thu, 30 Jun 2011 06:31:39 -0700 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action: draft-ietf-behave-ftp64-11.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, 30 Jun 2011 13:31:39 -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-11.txt Pages : 17 Date : 2011-06-30 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-11.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-11.txt From zhengyli@cisco.com Thu Jun 30 06:34:31 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 2BE2C11E8124 for ; Thu, 30 Jun 2011 06:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.969 X-Spam-Level: X-Spam-Status: No, score=-8.969 tagged_above=-999 required=5 tests=[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 X1ohc7+H+W8C for ; Thu, 30 Jun 2011 06:34:30 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id CD18E11E810C for ; Thu, 30 Jun 2011 06:34:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=zhengyli@cisco.com; l=3341; q=dns/txt; s=iport; t=1309440870; x=1310650470; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=CDMhgCujcK391xbT3bNBm2usaprBVC1sxFsq1rkpjr0=; b=H1dAxXGjpqheCV8y6K16ZReF6Thm6H1Uj3i8K60OFRlTaRqrkF967AX1 CJn9x3oa31eZSwarSqPxzF8WJYV+VkEP4dmXQ07tlVUOMKq65H9xcXB05 Fg9p5XMOe0YMjotWk3wa11PIW59x1W806H9mFx5XrDYLFFKZ0Jx2LVWG7 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIx6DE5Io8US/2dsb2JhbABSp1R3qimdfYYxBIc+inGEdotF X-IronPort-AV: E=Sophos;i="4.65,450,1304294400"; d="scan'208";a="99018307" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-1.cisco.com with ESMTP; 30 Jun 2011 13:34:21 +0000 Received: from [10.79.127.226] ([10.79.127.226]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5UDYI4X025793; Thu, 30 Jun 2011 13:34:19 GMT User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Thu, 30 Jun 2011 21:34:14 +0800 From: Rockson Li To: Iljitsch van Beijnum Message-ID: Thread-Topic: question on draft-ietf-behave-ftp64-10.txt In-Reply-To: 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: Re: [BEHAVE] question on draft-ietf-behave-ftp64-10.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, 30 Jun 2011 13:34:31 -0000 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. What do you think? On 6/30/11 7:29 PM, "Iljitsch van Beijnum" wrote: >On 30 jun 2011, at 11:50, Rockson Li wrote: > >>> An ALG MUST adopt the first option, and allow a client and a server >>> to negotiate security mechanisms. 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. >>> This applies even if the AUTH command is unsuccessful. > >> [RL] if the server cannot support the security extention client proposed >> and retur a >> failure response, why ALG needs to continue work in transparent >>mode? > >Because this way, if the client issues AUTH it knows the server went into >transparent mode. > >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? > >>> If the address specified in the EPRT command is an IPv4 address or an >>> IPv6 address that is not the IPv6 address used by the client for the >>> control session, the ALG SHOULD NOT attempt any translation, but pass >>> along the command unchanged. > >> [RL] FTP allow a control sessions to establish a data connection for two >> remote hosts. >> Why ALG should not attempt to do the translation if different IPv6 >> address used by the client for the >> control session, > >In that case, the client is almost certainly trying to do a >server-to-server transfer, a specification that allows for this would be >long and complex and very likely still not cover all possible cases. I >think there was some attempt to do this in an earlier version, but I >can't find it right now (there have been 18 versions of the draft so >far...). And see Fernando's messages, this is no longer a widely >supported mode of operation for FTP. > >So if people want to do this they'll have to calculate the right IPv6 >addresses themselves. > >>> Whenever a command from the client is not propagated to the server, >>> the FTP ALG instead issues a NOOP command in order to keep the >>> keepalive state between the client and the server synchronized > >> [RL] I don't quite understand the point here, why we need NOOP to >> synchronize >> client and server? if ALG choose to reponds the request itself, why >> server >> care about NOOP here? > >A client may track how long ago it last sent a command to the server and >issue a NOOP to avoid a timeout. If a command from the client never >reaches the server this strategy no longer works. So the requirement >above makes sure that whenever the client issues a command, the server >receives a command, even if it's just a NOOP. > >Iljitsch From iljitsch@muada.com Thu Jun 30 06:39:52 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 3278211E8155 for ; Thu, 30 Jun 2011 06:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.274 X-Spam-Level: X-Spam-Status: No, score=-102.274 tagged_above=-999 required=5 tests=[AWL=0.326, 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 TAijlPdRgycM for ; Thu, 30 Jun 2011 06:39:51 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id 9344B11E80CF for ; Thu, 30 Jun 2011 06:39:50 -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 p5UDeJIG011869 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 30 Jun 2011 15:40:19 +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, 30 Jun 2011 15:39:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5519AAAE-446E-4DF9-B487-ED5CEE72DEC5@muada.com> References: To: Rockson Li X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-behave-ftp64.all@tools.ietf.org, behave@ietf.org Subject: Re: [BEHAVE] question on draft-ietf-behave-ftp64-10.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, 30 Jun 2011 13:39:52 -0000 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 Thu Jun 30 06:45:31 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 BC79E11E80CC; Thu, 30 Jun 2011 06:45:31 -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 xT2NW0q2OXmF; Thu, 30 Jun 2011 06:45:31 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD5511E80BF; Thu, 30 Jun 2011 06:45:30 -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 p5UDjq4O011921 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 30 Jun 2011 15:45:53 +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: <817780D4-1CF0-4A5A-90A8-E8BF98A2274F@muada.com> Date: Thu, 30 Jun 2011 15:45:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <44C34387-A958-41E9-9363-D8DB7EBBCEF0@muada.com> References: <04C1AFDBEA554F3FA5FDD978C1682D6E@davidPC> <817780D4-1CF0-4A5A-90A8-E8BF98A2274F@muada.com> To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-behave-ftp64@tools.ietf.org, fgont@acm.org, "behave@ietf.orgWG WG" , "ietf@ietf.org Discussion" , Daniel Stenberg , ftpext@ietf.org, TSV Area , "behave-chairs@tools.ietf.org Chairs" , Fernando Gont , TSV Dir , draft-ietf-behave-ftp64.all@tools.ietf.org, David Harrington , Pekka Savola Subject: Re: [BEHAVE] FW: Last Call: (An FTP ALG for IPv6-to-IPv4 translation) to Proposed Standard 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, 30 Jun 2011 13:45:31 -0000 [Please note that this message is going to many mailing lists, please = trim as appropriate when responding.] I submitted a new version of the draft which addresses most, if not all = comments. The most notable change, which I would like to ask previous reviewers to = look at again, is the handling of the AUTH command, which is now made = much less prominent as a way to make the ALG transparent (clients should = use ALGS for this) so text specifying interaction of multiple ALGs could = be removed. The draft: http://tools.ietf.org/html/draft-ietf-behave-ftp64-11 The diff with -10: = http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-behave= -ftp64-11.txt Thanks everyone for reviewing.= From teemu.savolainen@nokia.com Thu Jun 30 12:13:49 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 608B211E8086 for ; Thu, 30 Jun 2011 12:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UdBeCIcOxpbV for ; Thu, 30 Jun 2011 12:13:49 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 94D1D11E807D for ; Thu, 30 Jun 2011 12:13:48 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p5UJDMW2004049; Thu, 30 Jun 2011 22:13:23 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 30 Jun 2011 22:13:22 +0300 Received: from 008-AM1MMR1-001.mgdnok.nokia.com (65.54.30.56) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 30 Jun 2011 21:13:22 +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; Thu, 30 Jun 2011 21:13:21 +0200 From: To: , Thread-Topic: [BEHAVE] What is the purpose to consider the non-standard IPv6 address formats in NSP discovery using WKN? Thread-Index: AQHMNxdEX1/MHQDUXkiXIdWCfylnmZTWRV7r Date: Thu, 30 Jun 2011 19:13:20 +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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 30 Jun 2011 19:13:22.0903 (UTC) FILETIME=[C7B4BE70:01CC3759] X-Nokia-AV: Clean Subject: Re: [BEHAVE] What is the purpose to consider the non-standard IPv6 address 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: Thu, 30 Jun 2011 19:13:49 -0000 Hi, I wrote the text thinking that networks may some day have some reason to no= t follow RFC6052 guidance for the address format (or even new formats may b= e designed by IETF), but host at the same time has need to be able to detec= t the NSP. Of the section 3.2 I agree cases 2 and 3 are quite long shots (and could be= removed I think), but the case 1 of just different alignment of IPv4 addre= ss in NSP would be more reasonable to support. The ability to fetch out NSP (suffix etc) correctly of non-standard format = is of course a challenge (but failing connection is often bad user experien= ce). On the other hand, I don't see why a node should not attempt to detect non-= standard NSP. Best regards, Teemu -----Original Message----- From: ext lizhenqiang@chinamobile.com Sent: 30/06/2011, 14:17 To: behave@ietf.org Subject: [BEHAVE] What is the purpose to consider the non-standard IPv6 add= ress formats in NSP discovery using WKN? Hello Everyone, Setion 3.2 of draft-ietf-behave-nat64-discovery-heuristic-01 considers non-= standard IPv6 address formats. I want to know the purpose. This condition v= iolates what is described in RFC6052.Why not treat this condition as error?= Even after performing more complex heuristics, a node finds the IPv4 addre= ss for the WKN, the node is difficult to decide the NSP from the returned I= Pv6 address. Best Regards, Zhenqiang Li 2011-06-30 _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From huitema@microsoft.com Thu Jun 30 14:26:52 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 8225E21F8839 for ; Thu, 30 Jun 2011 14:26:52 -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 AUkmhm7F-AwC for ; Thu, 30 Jun 2011 14:26:51 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 305A821F8834 for ; Thu, 30 Jun 2011 14:26:51 -0700 (PDT) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 30 Jun 2011 14:26:50 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) with Microsoft SMTP Server (TLS) id 14.1.289.8; Thu, 30 Jun 2011 14:26:50 -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; Thu, 30 Jun 2011 14:26:50 -0700 From: Christian Huitema To: "teemu.savolainen@nokia.com" , "behave@ietf.org" , "lizhenqiang@chinamobile.com" Thread-Topic: [BEHAVE] What is the purpose to consider the non-standard IPv6 address formats in NSP discovery using WKN? Thread-Index: AQHMNxdAbAWF4j1gcU6YGXmXdQQW5JTWurYA//+ugLA= Date: Thu, 30 Jun 2011 21:26:49 +0000 Message-ID: <22F6318E46E26B498ABC828879B08D4F1A13B2@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.42] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] What is the purpose to consider the non-standard IPv6 address 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: Thu, 30 Jun 2011 21:26:52 -0000 > On the other hand, I don't see why a node should not attempt to detect no= n-standard NSP. Detecting a non-standard NSP is only useful if the node understands how the= nonstandard addresses are built, which presumably requires a bit more than= simple pattern matching. I think it would be simpler to place the non-standard NSP as firmly out of = scope for the "standard" discovery draft. You can always add a simple parag= raph, something like "Developers MAY over time learn on IPv6 translated address format that are = extensions or alternatives to the standard formats. They MAY at that point = add additional steps to the proposed discovery procedures. These additional= steps are outside the scope of the present document." -- Christian Huitema From lizhenqiang@chinamobile.com Thu Jun 30 19:34:07 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 C163311E81BA for ; Thu, 30 Jun 2011 19:34:07 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: 1.011 X-Spam-Level: * X-Spam-Status: No, score=1.011 tagged_above=-999 required=5 tests=[AWL=0.788, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RELAY_IS_221=2.222] 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 L-SNtORarBm0 for ; Thu, 30 Jun 2011 19:34:07 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 316ED11E8092 for ; Thu, 30 Jun 2011 19:34:06 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id E0523A7D6; Fri, 1 Jul 2011 10:33:59 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id D25F3A7CB; Fri, 1 Jul 2011 10:33:59 +0800 (CST) To: Christian Huitema, teemu.savolainen@nokia.com, behave@ietf.org MIME-Version: 1.0 From: lizhenqiang@chinamobile.com Date: Fri, 1 Jul 2011 10:33:56 +0800 Message-ID: X-Mailer: Lotus Domino Web Server Release 6.5.6 March 06, 2007 X-MIMETrack: Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-07-01 10:33:59 MIME-Version: 1.0 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18232.003 X-TM-AS-Result: No--6.113-7.0-31-10 X-imss-scan-details: No--6.113-7.0-31-10;No--6.113-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No 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 02:34:07 -0000 I agree with Christian Huitema. We need not to standardize the non-standard= thing. Zhenqiang Li 2011-07-01=20 -----Original Message----- From: Christian Huitema=20 Sent: 2011-07-01 05:27:19=20 To: teemu.savolainen@nokia.com; behave@ietf.org; lizhenqiang@chinamobile.c= om=20 Subject: RE: [BEHAVE] What is the purpose to consider the non-standard IPv6= address formats in NSP discovery using WKN?=20 =20 > On the other hand, I don't see why a node should not attempt to detect no= n-standard NSP. Detecting a non-standard NSP is only useful if the node understands how the= nonstandard addresses are built, which presumably requires a bit more than= simple pattern matching. I think it would be simpler to place the non-standard NSP as firmly out of = scope for the "standard" discovery draft. You can always add a simple parag= raph, something like "Developers MAY over time learn on IPv6 translated address format that are = extensions or alternatives to the standard formats. They MAY at that point = add additional steps to the proposed discovery procedures. These additional= steps are outside the scope of the present document." -- Christian Huitema= From lizhenqiang@chinamobile.com Thu Jun 30 20:20: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 0F1831F0C4B for ; Thu, 30 Jun 2011 20:20:26 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: 0.854 X-Spam-Level: X-Spam-Status: No, score=0.854 tagged_above=-999 required=5 tests=[AWL=0.631, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RELAY_IS_221=2.222] 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 UtZ1kX2AfY2v for ; Thu, 30 Jun 2011 20:20:25 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 6EDAF1F0C47 for ; Thu, 30 Jun 2011 20:20:22 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id A1589A7A2; Fri, 1 Jul 2011 10:29:01 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 9A99FA79C; Fri, 1 Jul 2011 10:29:01 +0800 (CST) To: teemu.savolainen@nokia.com, behave@ietf.org MIME-Version: 1.0 From: lizhenqiang@chinamobile.com Date: Fri, 1 Jul 2011 10:28:59 +0800 Message-ID: X-Mailer: Lotus Domino Web Server Release 6.5.6 March 06, 2007 X-MIMETrack: Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-07-01 10:29:01 MIME-Version: 1.0 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18232.003 X-TM-AS-Result: No--12.283-7.0-31-10 X-imss-scan-details: No--12.283-7.0-31-10;No--12.283-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No Subject: Re: [BEHAVE] What is the purpose to consider the non-standard IPv6 address 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 03:20:26 -0000 Hi Teemu and all, Do you mean RFC6052 needs to be improved? I still do not see the reason to standardize the behavior that does not fol= low the standards. If some guy or node wants to do some private thing in th= e specific environment, just let him do it, we do not need to and can not s= ay anything about him. Private behavior is out of the scope of a public sta= ndard. Technically, if we can not detect the NSP correctly after the heuristics, w= hy to do it?=20 I suggest revome this section. Or just mention some words like "NSP discove= ry from the non-standard IPv6 address formats is out of the scope of this d= ocument". Best Regards, Zhenqiang Li 2011-07-01=20 -----Original Message----- From:teemu.savolainen@nokia.com=20 Sent: 2011-07-01 03:13:47=20 To: behave@ietf.org; lizhenqiang@chinamobile.com=20 Subject: RE: [BEHAVE] What is the purpose to consider the non-standard IPv6= address formats in NSP discovery u=20 =20 Hi, I wrote the text thinking that networks may some day have some reason to no= t follow RFC6052 guidance for the address format (or even new formats may b= e designed by IETF), but host at the same time has need to be able to detec= t the NSP. Of the section 3.2 I agree cases 2 and 3 are quite long shots (and could be= removed I think), but the case 1 of just different alignment of IPv4 addre= ss in NSP would be more reasonable to support. The ability to fetch out NSP (suffix etc) correctly of non-standard format = is of course a challenge (but failing connection is often bad user experien= ce). On the other hand, I don't see why a node should not attempt to detect non-= standard NSP. Best regards, Teemu -----Original Message----- From: ext lizhenqiang@chinamobile.com Sent: 30/06/2011, 14:17 To: behave@ietf.org Subject: [BEHAVE] What is the purpose to consider the non-standard IPv6 add= ress formats in NSP discovery using WKN? Hello Everyone, Setion 3.2 of draft-ietf-behave-nat64-discovery-heuristic-01 considers non-= standard IPv6 address formats. I want to know the purpose. This condition v= iolates what is described in RFC6052.Why not treat this condition as error?= Even after performing more complex heuristics, a node finds the IPv4 addre= ss for the WKN, the node is difficult to decide the NSP from the returned I= Pv6 address. Best Regards, Zhenqiang Li 2011-06-30 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave= From lizhenqiang@chinamobile.com Thu Jun 30 21:03: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 09B5521F8720 for ; Thu, 30 Jun 2011 21:03:55 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: 0.449 X-Spam-Level: X-Spam-Status: No, score=0.449 tagged_above=-999 required=5 tests=[AWL=0.826, BAYES_00=-2.599, RELAY_IS_221=2.222] 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 x81DiKVnxHAc for ; Thu, 30 Jun 2011 21:03:54 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 73ECB21F864F for ; Thu, 30 Jun 2011 21:03:54 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 7C22AA18B; Fri, 1 Jul 2011 12:03:52 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 70EECA17A; Fri, 1 Jul 2011 12:03:52 +0800 (CST) To: Dacheng Zhang(Dacheng), behave@ietf.org MIME-Version: 1.0 From: lizhenqiang@chinamobile.com Date: Fri, 1 Jul 2011 12:03:50 +0800 Message-ID: X-Mailer: Lotus Domino Web Server Release 6.5.6 March 06, 2007 X-MIMETrack: Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-07-01 12:03:51 MIME-Version: 1.0 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18232.004 X-TM-AS-Result: No--2.966-7.0-31-10 X-imss-scan-details: No--2.966-7.0-31-10;No--2.966-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No Subject: [BEHAVE] question about draft-zhang-behave-nat64-load-balancing 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 04:03:55 -0000 Hello Mr zhang and all, Zhenqiang Li from China Mobile. Two question about the draft. 1. Why the following is a problem? Traditional NAT44 also has this problem.= The privacy extension enven encourages user to change its source address. A user accessing multiple IPv4 servers may be represented by multiple p= ublic IPv4 addresses since its traffic may be processed by different NAT64 = systems. =20 2. Accordingly, in the section of basic load balancing considerations, I d= o not think the following is a problem. The widely-deployed NAT44 can not e= ven guarantee this point.=20 The load balancing SHOULD persevere the assignment of the same external IPv= 4 address for all active sessions initiated by an IPv6-only host. Best Regards, Zhenqiang Li=20 From cb.list6@gmail.com Thu Jun 30 22:23: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 499E211E80A4 for ; Thu, 30 Jun 2011 22:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.221 X-Spam-Level: X-Spam-Status: No, score=-2.221 tagged_above=-999 required=5 tests=[AWL=1.378, 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 BK3AVCXvU+oz for ; Thu, 30 Jun 2011 22:23:42 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 13EEC11E8092 for ; Thu, 30 Jun 2011 22:23:41 -0700 (PDT) Received: by wyj26 with SMTP id 26so2268949wyj.31 for ; Thu, 30 Jun 2011 22:23:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=wjhW2r3AXtvkhZMZsG55vSYTytBQXOjtSZ/1q18l3jM=; b=o3X61MvboVlcwsIV0JSYDmEkHOwauzWxqe4BegFHPeFmCl0EBZ8NbLZThf59md/DuO U7aeocvGDSSMrZq4fUM0YAzRzsRd6cRzj0irF+6PyUzlntTHa9HdQdxTp3es52+VaZtV ge54Bqz/V3WIixgrpxhO7xgiK+Y3pAd+XgoUI= MIME-Version: 1.0 Received: by 10.216.82.205 with SMTP id o55mr707094wee.64.1309497820963; Thu, 30 Jun 2011 22:23:40 -0700 (PDT) Received: by 10.216.39.83 with HTTP; Thu, 30 Jun 2011 22:23:40 -0700 (PDT) In-Reply-To: References: Date: Thu, 30 Jun 2011 22:23:40 -0700 Message-ID: From: Cameron Byrne To: lizhenqiang@chinamobile.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Dacheng Zhang , "behave@ietf.org" Subject: Re: [BEHAVE] question about draft-zhang-behave-nat64-load-balancing 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 05:23:46 -0000 Hi Zhengjiang, On Thu, Jun 30, 2011 at 9:03 PM, wrote: > Hello Mr zhang and all, > > Zhenqiang Li from China Mobile. Two question about the draft. > > 1. Why the following is a problem? Traditional NAT44 also has this proble= m. The privacy extension enven encourages user to change its source address= . Regarding privacy extensions, RFC4941 section 3.6 explicitly notes this risk of changing the address. I believe the expired addresses can still receive open sessions but do not initiate new ones ... but i suppose this depends on the implementation.... Yet, this is an IPv6 behavior, not an IPv4 and therefore not entirely germane to your question. > =A0 =A0A user accessing multiple IPv4 servers may be represented by multi= ple public IPv4 addresses since its traffic may be processed by different N= AT64 systems. > This is likely to cause a challenge for any protocol that have separate command and bearer channels, like SIP, PPTP, RTSP, and IPsec. It is unlikely that your IPsec session will work correctly if the peer receives IKE from one IPv4 address and ESP/UDP from another address. Most CGNs i have seen allow for address persistence to avoid this challenging behavior. In my testing, if i recall correctly, I believe Microsoft Web Outlook and the Juniper SSL client also fail when more than one address is used. > 2. Accordingly, in the section of =A0basic load balancing considerations,= I do not think the following is a problem. The widely-deployed NAT44 can n= ot even guarantee this point. > The load balancing SHOULD persevere the assignment of the same external I= Pv4 address for all active sessions initiated by an IPv6-only host. > I think all major CDNs do persistence today OpenBSD can do persistence with the "source-hast" key words http://www.openbsd.org/faq/pf/pools.html Juniper example http://kb.juniper.net/InfoCenter/index?page=3Dcontent&id=3DKB6374 I am pretty sure all major CGN providers see this as a basic feature that has substantial benefit. This behavior is also referenced in rfc4787 and draft-ietf-behave-lsn-requirements-01 "REQ-1: A CGN MUST have an "IP address pooling" behaviour of "Paired". Justification: This is a stronger form of REQ-2 from [RFC4787]. Note that this requirement applies regardless of the transport protocol. In other words, a CGN must use the same external IP address mapping for all sessions associated with the same internal IP address, be they TCP, UDP, ICMP, something else, or a mix of different protocols. " > Best Regards, > Zhenqiang Li > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave >