From dwing@cisco.com Tue Dec 7 11:34:33 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C6B03A6884; Tue, 7 Dec 2010 11:34:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Z0HsaBdVGfm; Tue, 7 Dec 2010 11:34:27 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 2EE2C3A687E; Tue, 7 Dec 2010 11:34:27 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAOgb/kytJV2a/2dsb2JhbACVMoEljG5xpkObUoVJBIRi Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-1.cisco.com with ESMTP; 07 Dec 2010 19:35:52 +0000 Received: from dwingWS ([10.32.240.196]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id oB7JZq7J032748; Tue, 7 Dec 2010 19:35:52 GMT From: "Dan Wing" To: Date: Tue, 7 Dec 2010 11:35:52 -0800 Message-ID: <08e501cb9645$f5ab5fb0$e1021f10$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 X-IronPort-AV: E=Sophos; i="4.59,311,1288569600"; d="scan'208"; a="216863971" X-OriginalArrivalTime: 07 Dec 2010 19:18:42.0867 (UTC) FILETIME=[8FBCA030:01CB9643] Thread-Index: AcuWQ444HbRVqwT2RQasdGvxY19mEg== Content-Language: en-us Cc: behave@ietf.org Subject: [BEHAVE] [pcp] discuss: open ICMP as side-effect X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: pcp@ietf.org List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2010 19:34:33 -0000 (Sorry, resending this one because I neglected to CC the BEHAVE working group. Please direct replies to pcp@ietf.org) This is one of the PCP discussion points. This question is CC'd to BEHAVE, as it was suggested BEHAVE should provide input on this question. The question is simple: when PCP is used to open a UDP/TCP port, should the NAT, as a side effect: (a) also allow ICMP messages associated with that UDP/TCP flow. For example, allow ICMP packet-too-big messages associated with that flow. or (b) not allow ICMP messages associated with that UDP/TCP flow. This means PCP (the protocol) and the PCP client would need to explicitly permit ICMP messages associated with the UDP/TCP flow, if the PCP client wants those associated ICMP messages. I read over BEHAVE's " NAT Behavioral Requirements for ICMP", RFC5508, and it does not say that ICMP messages should be allowed as a side effect of a UDP or TCP flow. It is my *personal* understanding that (a) BEHAVE expects that a TCP/UDP flow would allow the associated ICMP messages to be NATed. and (b) Based on (a), I feel PCP should mimic that behavior, and should allow the associated ICMP messages as a side-effect of opening a TCP/UDP flow. -d _______________________________________________ pcp mailing list pcp@ietf.org https://www.ietf.org/mailman/listinfo/pcp From simon.perreault@viagenie.ca Tue Dec 7 12:52:47 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFCF728C0E0; Tue, 7 Dec 2010 12:52:47 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4UTd9YiITpyr; Tue, 7 Dec 2010 12:52:47 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id E6DEC28C0E1; Tue, 7 Dec 2010 12:52:46 -0800 (PST) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:21d:60ff:fed7:e732]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 6356420CF1; Tue, 7 Dec 2010 15:54:12 -0500 (EST) Message-ID: <4CFE9EF3.2060509@viagenie.ca> Date: Tue, 07 Dec 2010 15:54:11 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.12) Gecko/20101103 Fedora/1.0-0.33.b2pre.fc14 Thunderbird/3.1.6 MIME-Version: 1.0 To: pcp@ietf.org References: <08e501cb9645$f5ab5fb0$e1021f10$@com> In-Reply-To: <08e501cb9645$f5ab5fb0$e1021f10$@com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: behave@ietf.org, Dan Wing Subject: Re: [BEHAVE] [pcp] discuss: open ICMP as side-effect X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2010 20:52:48 -0000 On 2010-12-07 14:35, Dan Wing wrote: > I read over BEHAVE's " NAT Behavioral Requirements for ICMP", RFC5508, > and it does not say that ICMP messages should be allowed as a > side effect of a UDP or TCP flow. > > It is my *personal* understanding that > (a) BEHAVE expects that a TCP/UDP flow would allow > the associated ICMP messages to be NATed. > and > (b) Based on (a), I feel PCP should mimic that behavior, > and should allow the associated ICMP messages as > a side-effect of opening a TCP/UDP flow. Fully agreed. BEHAVE documented this in the specification of NAT64. A NAT64 device implementing PCP should not need to differentiate between PCP flows and regular flows. They should all be the same: allow translation of associated ICMP messages implicitly. 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 dthaler@microsoft.com Tue Dec 7 12:53:41 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 475CE3A6835; Tue, 7 Dec 2010 12:53:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.525 X-Spam-Level: X-Spam-Status: No, score=-110.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVOTrQTlZ4nw; Tue, 7 Dec 2010 12:53:40 -0800 (PST) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id EBC2C28C0E7; Tue, 7 Dec 2010 12:53:39 -0800 (PST) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 7 Dec 2010 12:55:05 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.1.255.3; Tue, 7 Dec 2010 12:55:05 -0800 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.99]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Tue, 7 Dec 2010 12:55:06 -0800 From: Dave Thaler To: "pcp@ietf.org" Thread-Topic: [pcp] discuss: open ICMP as side-effect Thread-Index: AcuWQ444HbRVqwT2RQasdGvxY19mEgADUWlQ Date: Tue, 7 Dec 2010 20:55:03 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF6534431ACC@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <08e501cb9645$f5ab5fb0$e1021f10$@com> In-Reply-To: <08e501cb9645$f5ab5fb0$e1021f10$@com> 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 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] [pcp] discuss: open ICMP as side-effect X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2010 20:53:41 -0000 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of Dan > Wing > Sent: Tuesday, December 07, 2010 11:36 AM > To: pcp@ietf.org > Cc: behave@ietf.org > Subject: [pcp] discuss: open ICMP as side-effect >=20 > (Sorry, resending this one because I neglected to CC the BEHAVE working g= roup. > Please direct replies to pcp@ietf.org) >=20 > This is one of the PCP discussion points. >=20 > This question is CC'd to BEHAVE, as it was suggested BEHAVE should provid= e > input on this question. >=20 > The question is simple: when PCP is used to open a UDP/TCP port, should = the > NAT, as a side effect: >=20 > (a) also allow ICMP messages associated with that UDP/TCP > flow. For example, allow ICMP packet-too-big messages > associated with that flow. > or > (b) not allow ICMP messages associated with that UDP/TCP > flow. This means PCP (the protocol) and the PCP > client would need to explicitly permit ICMP messages > associated with the UDP/TCP flow, if the PCP client > wants those associated ICMP messages. >=20 > I read over BEHAVE's " NAT Behavioral Requirements for ICMP", RFC5508, an= d it > does not say that ICMP messages should be allowed as a side effect of a U= DP or > TCP flow. >=20 > It is my *personal* understanding that > (a) BEHAVE expects that a TCP/UDP flow would allow > the associated ICMP messages to be NATed. > and > (b) Based on (a), I feel PCP should mimic that behavior, > and should allow the associated ICMP messages as > a side-effect of opening a TCP/UDP flow. Personal opinion: I agree PCP's behavior should match the behavior resulting from a data packet that creates a mapping. So my understanding is the same as yours. -Dave >=20 > -d >=20 >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From cb.list6@gmail.com Tue Dec 7 14:49:42 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80DD03A683D for ; Tue, 7 Dec 2010 14:49:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.792 X-Spam-Level: X-Spam-Status: No, score=-2.792 tagged_above=-999 required=5 tests=[AWL=0.807, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7DqS5V+OFQDj for ; Tue, 7 Dec 2010 14:49:40 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 17B073A6887 for ; Tue, 7 Dec 2010 14:49:40 -0800 (PST) Received: by qwg5 with SMTP id 5so472186qwg.31 for ; Tue, 07 Dec 2010 14:51:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=YD0R2/MMHVb/FdXdFE4Fv6hhXSzPPfx5a7j27H9NCuc=; b=X3Ao31ILi72aY4820t/RiiQ7tSSxCVD9eshj4N5o6NDYhkzz5XTyaC4YSV60MXsyTX /DH75auQZSwvo74R1CW9dXHF+JVUtYBf/oj9OQDZWl/Ee7bWb/3haZEhTOYY/WcHH4H4 0gFmVnoEehpt1E+2PEiwLvo53VjtCZVoKj87o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=u1boghMvACoDFRBY46R0bHc+BRnD15ezHdr43e498PkDjHebyrN6oQVJhmbG87UQhD wLDRIIDh+gCtdl+eeX3SzFLGnWWRnqn4rNQ397+I63/sBUAJQhuzrrtWsgSkV5f7+NnX KWwnd1NsiVI3eA185mZwOkF9b1oeHRZOIUxTs= MIME-Version: 1.0 Received: by 10.229.235.4 with SMTP id ke4mr6679504qcb.201.1291762266119; Tue, 07 Dec 2010 14:51:06 -0800 (PST) Received: by 10.229.9.198 with HTTP; Tue, 7 Dec 2010 14:51:06 -0800 (PST) Date: Tue, 7 Dec 2010 14:51:06 -0800 Message-ID: From: Cameron Byrne To: behave@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [BEHAVE] IPv4 literals X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2010 22:49:42 -0000 Here is an interesting project that has popped on the T-Mobile USA IPv6 FUT network. The N900 now has some tricks to help with IPv4 literals in the IPv6-only NAT64 environment http://code.google.com/p/n900ipv6/wiki/LDPreloadNat64 It requires the manual definition of the PREF64, but could likely be modified to use WKP as a default or one of the PREF64 discover methods Cameron From dwing@cisco.com Tue Dec 7 18:44:31 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C2583A6848 for ; Tue, 7 Dec 2010 18:44:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.558 X-Spam-Level: X-Spam-Status: No, score=-110.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqg3Rzvasv3T for ; Tue, 7 Dec 2010 18:44:30 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 25D203A682B for ; Tue, 7 Dec 2010 18:44:30 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAK6A/kyrR7Hu/2dsb2JhbACWXIxucaVxmz2FSQSEYg X-IronPort-AV: E=Sophos;i="4.59,314,1288569600"; d="scan'208";a="388767632" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 08 Dec 2010 02:45:56 +0000 Received: from dwingWS ([10.32.240.196]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id oB82ju8c005017; Wed, 8 Dec 2010 02:45:56 GMT From: "Dan Wing" To: "'Cameron Byrne'" , References: In-Reply-To: Date: Tue, 7 Dec 2010 18:45:56 -0800 Message-ID: <0b2e01cb9682$0a393fb0$1eabbf10$@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: AcuWYWYmowpwSCSeT+KHBLOXzBS4iQAIHhIw Content-Language: en-us Subject: Re: [BEHAVE] IPv4 literals X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2010 02:44:31 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Cameron Byrne > Sent: Tuesday, December 07, 2010 2:51 PM > To: behave@ietf.org > Subject: [BEHAVE] IPv4 literals > > Here is an interesting project that has popped on the T-Mobile USA > IPv6 FUT network. > > The N900 now has some tricks to help with IPv4 literals in the > IPv6-only NAT64 environment > > http://code.google.com/p/n900ipv6/wiki/LDPreloadNat64 Thanks for the pointer. It is effectively doing NAT46 in the host, which results in a system that is NAT464 (NAT46 in the host and NAT64 in the network). > It requires the manual definition of the PREF64, but could likely be > modified to use WKP as a default or one of the PREF64 discover methods Yep. -d From cb.list6@gmail.com Sat Dec 18 13:51:29 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39BEF3A6BF1 for ; Sat, 18 Dec 2010 13:51:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.978 X-Spam-Level: X-Spam-Status: No, score=-2.978 tagged_above=-999 required=5 tests=[AWL=0.621, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rkkbRfol3tT8 for ; Sat, 18 Dec 2010 13:51:28 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 953C03A6BE8 for ; Sat, 18 Dec 2010 13:51:27 -0800 (PST) Received: by qyj19 with SMTP id 19so1873643qyj.10 for ; Sat, 18 Dec 2010 13:53:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=z3DmoBlWSq1kKmWjNG/98+4I8AcHtsFve1Q/OJOkYFE=; b=bzexH00VhIteo8ebHLDPL9LFCK65yLXOdKdL+aekC8817dUI/d9kZudZ9r0PMITgjj uNpyUSr/qnDenQjmj6ndgqrZ08XU4BMqZvnkJt6JtjejmyBFqzGJJrRqLozt0QMszkCw P/15Lj93OKfVpSCx4aO7NmDgmCSe/1ndPyNyQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=k8DKxexD7lf2DDUH8VWJQBy2Q+TNafMDBsUGI8IC3aI1YNaLuXlCKWUeEGgeJ3d6uf XuJeTUeRavJ+U2yiwQxmkGOfNlfjgDkhYx8rOkQfpwpvS0F08a2RcsmTMg9zgF8dve6b cHn+XfBp4tBO6PiLIGP5H81iqTmqmg5B4Jzic= MIME-Version: 1.0 Received: by 10.229.235.69 with SMTP id kf5mr2363230qcb.49.1292709197345; Sat, 18 Dec 2010 13:53:17 -0800 (PST) Received: by 10.229.106.214 with HTTP; Sat, 18 Dec 2010 13:53:17 -0800 (PST) Date: Sat, 18 Dec 2010 13:53:17 -0800 Message-ID: From: Cameron Byrne To: behave@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [BEHAVE] ULA as PREF64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Dec 2010 21:51:29 -0000 Are there any known limitations or problems with using ULA addresses as the PREF64? I do not want people from outside of my administrative domain to use my DNS64 and NAT64. Other mechanisms such as access lists will be used, but in an attempt to have a layered approach to this particular security issue, it seems to make sense that ULA be used as both the queried address of the DNS64 as well as the NSP PREF64 that will be used. Any concerns that i am overlooking? Thanks, cameron From simon.perreault@viagenie.ca Mon Dec 20 08:08:12 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 827E93A67D7 for ; Mon, 20 Dec 2010 08:08:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AN9rVKilEkaz for ; Mon, 20 Dec 2010 08:08:11 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 6F99E3A67AF for ; Mon, 20 Dec 2010 08:08:11 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id CC5272151B for ; Mon, 20 Dec 2010 11:10:03 -0500 (EST) Message-ID: <4D0F7FDB.6010104@viagenie.ca> Date: Mon, 20 Dec 2010 11:10:03 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.12) Gecko/20101103 Fedora/1.0-0.33.b2pre.fc14 Thunderbird/3.1.6 MIME-Version: 1.0 To: behave@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] ULA as PREF64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 16:08:12 -0000 On 2010-12-18 16:53, Cameron Byrne wrote: > I do not want people from outside of my administrative domain to use > my DNS64 and NAT64. Other mechanisms such as access lists will be > used, but in an attempt to have a layered approach to this particular > security issue, it seems to make sense that ULA be used as both the > queried address of the DNS64 as well as the NSP PREF64 that will be > used. ULAs are probably more likely to be filtered by the customer. Although in a mobile context you likely have more control over that... Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From Teemu.Kiviniemi@csc.fi Tue Dec 21 04:04:07 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F84C3A6869; Tue, 21 Dec 2010 04:04:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XXbursM7I7go; Tue, 21 Dec 2010 04:04:06 -0800 (PST) Received: from smtp3.csc.fi (smtp3.csc.fi [193.166.7.53]) by core3.amsl.com (Postfix) with ESMTP id DBE9B3A6868; Tue, 21 Dec 2010 04:04:05 -0800 (PST) Received: from kusti.csc.fi (kusti.csc.fi [193.166.0.100]) by smtp3.csc.fi (8.14.3/8.14.3/CSC) with ESMTP id oBLC5x10008446; Tue, 21 Dec 2010 14:05:59 +0200 Received: from [193.166.4.142] (193.166.4.142) by kusti.csc.fi (192.168.120.3) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 21 Dec 2010 14:07:04 +0200 From: Teemu Kiviniemi To: , Content-Type: text/plain Date: Tue, 21 Dec 2010 14:05:58 +0200 Message-ID: <1292933158.18519.393.camel@merihanhi.csc.fi> MIME-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-19.el5) Content-Transfer-Encoding: 7bit X-CanIt-Geo: ip=193.166.0.100; country=FI; latitude=64.0000; longitude=26.0000; http://maps.google.com/maps?q=64.0000,26.0000&z=6 X-CanItPRO-Stream: 00_Opt_Out (inherits from default) X-Scanned-By: CanIt (www . roaringpenguin . com) on 193.166.7.53 Subject: [BEHAVE] Announcing an IPv4 to IPv6 multicast translation service X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2010 12:04:07 -0000 Hi all, The Finnish University and Research Network Funet has started providing an IPv4 to IPv6 multicast translation service. The service enables IPv6 hosts to receive any IPv4 multicast as IPv6 multicast. The service can be used also outside the Funet network, in networks which support IPv6 multicast (e.g. M6Bone). The service is based on a translator implementation developed at CSC/Funet. The multicast translator is implemented as a new component of open source MRD6 multicast router on Linux. The implementation follows the architectural ideas and address translation presented in draft-venaas-behave-mcast46 Internet-Draft. IPv4 to IPv6 protocol translation is done using an adapted version of the SIIT algorithm (RFC 2765). Usage instructions and more information about the service are available at: http://www.csc.fi/english/institutions/funet/networkservices/ipv6/mcast46 Information about the implementation is available in my master's thesis: http://iki.fi/teemuki/translator/ The implementation is freely available in the MRD6 Git repository: http://fivebits.net/proj/mrd6/ -- Merry Christmas, Teemu Kiviniemi CSC/Funet From dthaler@microsoft.com Tue Dec 21 10:09:38 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 321873A6B2D for ; Tue, 21 Dec 2010 10:09:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.536 X-Spam-Level: X-Spam-Status: No, score=-110.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2W4BATLkEv0 for ; Tue, 21 Dec 2010 10:09:37 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 4921A3A6B00 for ; Tue, 21 Dec 2010 10:09:37 -0800 (PST) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 21 Dec 2010 10:11:33 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.1.255.3; Tue, 21 Dec 2010 10:11:33 -0800 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.151]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Tue, 21 Dec 2010 10:11:32 -0800 From: Dave Thaler To: Iljitsch van Beijnum Thread-Topic: [BEHAVE] one week WGLC, draft-ietf-behave-ftp64-05 Thread-Index: ActY6jKKLqeAf6WHSOikuiNZqgewtAH/d6IwBraFzQAJXXikgA== Date: Tue, 21 Dec 2010 18:11:29 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653447D195@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <0cac01cb58ea$32d19a60$9874cf20$@com> <9B57C850BB53634CACEC56EF4853FF65343005F2@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> 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 Cc: "draft-ietf-behave-ftp64@tools.ietf.org" , 'Behave WG' , "behave-chairs@tools.ietf.org" Subject: Re: [BEHAVE] one week WGLC, draft-ietf-behave-ftp64-05 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2010 18:09:38 -0000 Iljitsch van Beijnum wrote: > On 30 sep 2010, at 23:43, Dave Thaler wrote: > > The technical comment is that the text currently breaks > > internationalization as specified in RFC 2640 section 4, whereby the > > text part of responses can be > > UTF-8 non-English characters. Currently several places in draft -05 > > either appear to specify the literal response (in English) or constrain= the syntax > to be ALPHA. > > In contrast RFC 2640 section 4 specifies %x01-%xFF instead of ALPHA. [...] > I didn't change the freetext specification for RFC 2640 compliance becaus= e I'm > afraid this may break certain clients and the ALG is not in a good positi= on to > negotiate language or UTF8 support. I added this text: >=20 > specifies the ability for clients and servers= to > negotiate the language used text messages between the two of them. This w= ill > typically involve the use of UTF-8 encoded characters outside the 7-bit A= SCII > range. Because client compatibility with RFC 2640 is unknown, ALGs need a= dopt > a conservative position in this regard. As such, an ALG MUST NOT use any > characters outside of the 7-bit ASCII range in the text that it generates= . > However, an ALG MUST transparently forward commands and responses > containing UTF-8 encoded text when those occur. [...] That's not sufficient. RFC 2640 section 4.1 states: Once negotiated, server-PI MUST return server messages and textual part of command responses in the negotiated language and encoded in UTF-8. RFC 2640 section 4.3 states: A server-FTP process that supports the LANG command, and language support for messages and command responses, MUST include in the response to the FEAT command [RFC2389], a feature line indicating that the LANG command is supported and a fact list of the supported language tags. So if the FTP ALG allows the LANG command to succeed, and the FTP64 then generates text in a language (like English) other than the negotiated one, *that's* what "may break certain clients" as you say, because that would appear to the client that the server is violating the MUST in RFC 2640 section 4.1 above. Some languages might not even be representable in VCHAR's. If you believe "the ALG is not in a good position to negotiat= e language or UTF8 support" then you would want to prevent this from=20 occurring. I think the options for an FTP64 are a) always reject LANG command with an error-response (RFC 2640 section 4.2) In this solution, I think it should process the FEAT response and remov= e the fact that the LANG command is supported, or it may break certain clients that may expect it to succeed when the FEAT says it will. b) reject the LANG command with an error-response whenever the FTP64 cannot generate text in the specified language. In this solution, I think it should process the FEAT response and remove any language tags that it doesn't support, and remove the fact that the LANG command is supported if the list becomes empty. c) appear to violate the section 4.1 MUST and generate text in a language other than what the client expects. This is what the draft currently = implies and I think this is broken. I think (a) would be the simplest solution, though it prevents internationa= lization. (b) is the more powerful solution, but is probably overkill for a transitio= n mechanism that we don't want to be the recommended solution. -Dave From iljitsch@muada.com Tue Dec 21 14:59:03 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BC9C3A6AC8 for ; Tue, 21 Dec 2010 14:59:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.784 X-Spam-Level: X-Spam-Status: No, score=-101.784 tagged_above=-999 required=5 tests=[AWL=0.815, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3FRMEZoTBnC for ; Tue, 21 Dec 2010 14:59:02 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 92A7E3A6A6F for ; Tue, 21 Dec 2010 14:59:02 -0800 (PST) Received: from [192.168.0.193] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id oBLN0tTF060498 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 22 Dec 2010 00:00:56 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653447D195@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Date: Wed, 22 Dec 2010 00:00:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9C2CFA50-4870-4B37-A15B-524B8DC8289E@muada.com> References: <0cac01cb58ea$32d19a60$9874cf20$@com> <9B57C850BB53634CACEC56EF4853FF65343005F2@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447D195@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> To: Dave Thaler X-Mailer: Apple Mail (2.1082) Cc: "draft-ietf-behave-ftp64@tools.ietf.org" , 'Behave WG' , "behave-chairs@tools.ietf.org" Subject: Re: [BEHAVE] one week WGLC, draft-ietf-behave-ftp64-05 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2010 22:59:03 -0000 On 21 dec 2010, at 19:11, Dave Thaler wrote: >> As such, an ALG MUST NOT use any >> characters outside of the 7-bit ASCII range in the text that it = generates. >> However, an ALG MUST transparently forward commands and responses >> containing UTF-8 encoded text when those occur. > I think the options for an FTP64 are > a) always reject LANG command with an error-response (RFC 2640 section = 4.2) > In this solution, I think it should process the FEAT response and = remove > the fact that the LANG command is supported, or it may break = certain > clients that may expect it to succeed when the FEAT says it will. I don't like this, because it's too tricky. I don't know of any = implementations that support RFC 2640, and if those are not tested = against this solution can easily create subtle bugs. > b) reject the LANG command with an error-response whenever the FTP64 > cannot generate text in the specified language. In this solution, > I think it should process the FEAT response and remove any language > tags that it doesn't support, and remove the fact that the LANG = command > is supported if the list becomes empty. See above. > c) appear to violate the section 4.1 MUST and generate text in a = language > other than what the client expects. This is what the draft = currently implies > and I think this is broken. I don't think there is any solution that conforms to the spirit of RFC = 2640: that would be to provide text in the negotiated language. = Rejecting language negotiation may be correct protocol-wise, but it = really doens't help the user to get the text from the server in a = non-desired language just because the ALG can't generate responses in = that language. I'm going to ask on the ftpext list to see if anyone knows about RFC = 2640 implementations. If not, then the most prudent course of action = would be to move RFC 2640 to historic, IMO.= From dthaler@microsoft.com Tue Dec 21 16:30:08 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A59043A6910 for ; Tue, 21 Dec 2010 16:30:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.54 X-Spam-Level: X-Spam-Status: No, score=-110.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VnQ-NR1PK0s for ; Tue, 21 Dec 2010 16:30:07 -0800 (PST) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 5C8163A681F for ; Tue, 21 Dec 2010 16:30:07 -0800 (PST) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 21 Dec 2010 16:32:04 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.1.255.3; Tue, 21 Dec 2010 16:32:04 -0800 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.151]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Tue, 21 Dec 2010 16:32:04 -0800 From: Dave Thaler To: Iljitsch van Beijnum Thread-Topic: [BEHAVE] one week WGLC, draft-ietf-behave-ftp64-05 Thread-Index: ActY6jKKLqeAf6WHSOikuiNZqgewtAH/d6IwBraFzQAJXXikgAAN1huA Date: Wed, 22 Dec 2010 00:32:03 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653447ECAF@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <0cac01cb58ea$32d19a60$9874cf20$@com> <9B57C850BB53634CACEC56EF4853FF65343005F2@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447D195@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653447D195@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> 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 Cc: "draft-ietf-behave-ftp64@tools.ietf.org" , 'Behave WG' Subject: Re: [BEHAVE] one week WGLC, draft-ietf-behave-ftp64-05 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 00:30:08 -0000 To your later question, Microsoft's IIS does support RFC 2640 in its FTP server. Microsoft's current FTP clients, on the other hand, do = not support RFC 2640. -Dave From dwing@cisco.com Tue Dec 21 18:36:13 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FE053A6ABE for ; Tue, 21 Dec 2010 18:36:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.502 X-Spam-Level: X-Spam-Status: No, score=-110.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cilbut+ulesu for ; Tue, 21 Dec 2010 18:35:40 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 392323A6917 for ; Tue, 21 Dec 2010 18:35:40 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnAGABrzEE2rR7Ht/2dsb2JhbACVeYEljHRzpWibU4VJBIRl X-IronPort-AV: E=Sophos;i="4.60,210,1291593600"; d="scan'208";a="236282165" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 22 Dec 2010 02:37:37 +0000 Received: from dwingWS (sjc-vpn3-643.cisco.com [10.21.66.131]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oBM2bbI2029346 for ; Wed, 22 Dec 2010 02:37:37 GMT From: "Dan Wing" To: Date: Tue, 21 Dec 2010 18:37:37 -0800 Message-ID: <10fc01cba181$32180840$964818c0$@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: AcuhgTHn+47IJvZ/Tp2KCM4q4+0Tlg== Content-Language: en-us Subject: [BEHAVE] minutes posted X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 02:36:13 -0000 X-List-Received-Date: Wed, 22 Dec 2010 02:36:13 -0000 Minutes from IETF79 are now posted. Sorry for the delay. http://www.ietf.org/proceedings/79/minutes/behave.txt Thanks to Stuart Cheshire and Ed Jankiewicz for taking notes. -d From stmillet@cisco.com Tue Dec 21 20:48:41 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4E2E3A6993 for ; Tue, 21 Dec 2010 20:48:41 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 764lh7-DtZGB for ; Tue, 21 Dec 2010 20:48:38 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 671F23A68C5 for ; Tue, 21 Dec 2010 20:48:38 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAK0SEU2rRN+J/2dsb2JhbACkEnOlcJtZhUkEhGaJQQ X-IronPort-AV: E=Sophos;i="4.60,211,1291593600"; d="scan'208";a="236318383" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 22 Dec 2010 04:50:35 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id oBM4oZr6007097; Wed, 22 Dec 2010 04:50:35 GMT Received: from xmb-sjc-22e.amer.cisco.com ([128.107.191.115]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Dec 2010 20:50:35 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Dec 2010 20:50:33 -0800 Message-ID: <283E485E53107A4991ACFBEA65AC1A860805D354@xmb-sjc-22e.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] ULA as PREF64 Thread-Index: Acue/f+WiFTj4+iyTAOtfBlkBq+3lAClOd8Q References: From: "Stephan Millet (stmillet)" To: "Cameron Byrne" , X-OriginalArrivalTime: 22 Dec 2010 04:50:35.0881 (UTC) FILETIME=[C5AB8D90:01CBA193] Subject: Re: [BEHAVE] ULA as PREF64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 04:48:42 -0000 My 2c worth, Using ULAs will not allow your DNS64 to resolve using IPv6 as a transport when talking to IPv6 enabled root servers or other IPv6 enabled authoritative servers. If I can go slightly off topic, given that the NAT64 prefix is unique to your network how could it be used by people outside your administrative domain ? Other users could point their DNS queries to your DNS64, though when crap answers get returned, that behaviour should stop relatively quickly. (I am differentiating here between a DOS attack versus a misconfigured resolver)=20 Cheers ----=20 Stephan Millet=20 -----Original Message----- From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of Cameron Byrne Sent: Sunday, 19 December 2010 8:53 AM To: behave@ietf.org Subject: [BEHAVE] ULA as PREF64 Are there any known limitations or problems with using ULA addresses as the PREF64? I do not want people from outside of my administrative domain to use my DNS64 and NAT64. Other mechanisms such as access lists will be used, but in an attempt to have a layered approach to this particular security issue, it seems to make sense that ULA be used as both the queried address of the DNS64 as well as the NSP PREF64 that will be used. Any concerns that i am overlooking? Thanks, cameron _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From iljitsch@muada.com Wed Dec 22 03:40:25 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A75B63A6AD9; Wed, 22 Dec 2010 03:40:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCt6qzsT4DyX; Wed, 22 Dec 2010 03:39:19 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 64B113A6B14; Wed, 22 Dec 2010 03:39:19 -0800 (PST) Received: from claw.it.uc3m.es ([163.117.139.69]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id oBMBfDjQ063719 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 22 Dec 2010 12:41:13 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653447ECAF@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Date: Wed, 22 Dec 2010 12:40:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8B73074C-5B7E-425F-B8B2-C28757FB7CD6@muada.com> References: <0cac01cb58ea$32d19a60$9874cf20$@com> <9B57C850BB53634CACEC56EF4853FF65343005F2@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447D195@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447ECAF@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> To: Dave Thaler X-Mailer: Apple Mail (2.1082) Cc: draft-ietf-behave-ftp64@tools.ietf.org, ftpext@ietf.org, Behave WG Subject: Re: [BEHAVE] one week WGLC, draft-ietf-behave-ftp64-05 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 11:40:25 -0000 [CC to ftpext, please prune as desired when following up] On 22 dec 2010, at 1:32, Dave Thaler wrote: > To your later question, Microsoft's IIS does support RFC 2640 > in its FTP server. Microsoft's current FTP clients, on the other = hand, do not > support RFC 2640. And so does ProFTPD. I quickly checked maybe a dozen FTP sites. A few of them supported LANG, = although none any languages other than English, one UTF8 but not LANG, = one LANG but not FEAT (which is in non-conformance to RFC 2640). So I = guess a quick deprecation is off the table. After reading RFC 2640 a bit more closely, it turns out that it actually = allows CR/LFs in filenames, but those are escaped using a null = character. This probably warrants a warning in the FTP64 document, as = ALG implementers may not be aware of this and of course a null character = has special meaning in languages such as C. Back to the original problem. Ideally, the ALG would observe the LANG negotiation and then send text = in the desired language. However, there is no way to make sure that the = ALG supports all the languages that clients and servers may support, so = even if the ALG makes this attempt, there will be cases when it can't = provide text in the desired language. When that happens, there are two choices: 1. block the LANG negotiation and use the default language 2. ignore the LANG negotiation and use the default language The advantage of 1 is consistency. However, this is more complex to = implement and despite some evidence of LANG support I fear that actual = use of this feature is too low to see good real-world testing, so there = is a significant risk of bugs that won't come to light until the ALG is = widely deployed. Another downside is that the user is now deprived of = text in the desired language for text sent by the server that isn't = touched by the ALG. Most notably, this would be the greetings. With = failed LANG negotiation, users probably also wouldn't be able to use = UTF-8 user names, passwords or path names. The advantage of 2 is implementation simplicity and that the majority of = the text is still in the desired language. However, some server = responses will be in the ALG's (default) language rather than in the = negotiated language. (But informed users can still see what's going on = from the numeric response, the text is merely additional information.) I propose the following: - provide some explanation of the issue in the document - ALGs MUST support UTF-8 and the CR0LF thing - ALGs MAY monitor the LANG negotiation and adjust their language = accordingly (with no opinion about what happens when the ALG supports = the user desired language but the server doesn't) - if the ALG doesn't monitor the LANG negotiation or doesn't support the = negotiated language, it uses its default language Thoughts?= From behcetsarikaya@yahoo.com Wed Dec 22 08:23:49 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EE023A6B0F for ; Wed, 22 Dec 2010 08:23:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[AWL=0.435, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aB8M9iUJALL6 for ; Wed, 22 Dec 2010 08:23:48 -0800 (PST) Received: from nm29.bullet.mail.sp2.yahoo.com (nm29.bullet.mail.sp2.yahoo.com [98.139.91.99]) by core3.amsl.com (Postfix) with SMTP id A05F63A6B0C for ; Wed, 22 Dec 2010 08:23:48 -0800 (PST) Received: from [98.139.91.69] by nm29.bullet.mail.sp2.yahoo.com with NNFMP; 22 Dec 2010 16:25:44 -0000 Received: from [98.139.91.2] by tm9.bullet.mail.sp2.yahoo.com with NNFMP; 22 Dec 2010 16:25:44 -0000 Received: from [127.0.0.1] by omp1002.mail.sp2.yahoo.com with NNFMP; 22 Dec 2010 16:25:44 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 718795.81549.bm@omp1002.mail.sp2.yahoo.com Received: (qmail 66598 invoked by uid 60001); 22 Dec 2010 16:25:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1293035144; bh=bK/KGtv3kfqLK/O5U/KRIHCltAWOZDiOvzjkeTgLNkA=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=i2EcoV78ivyV+83primuT/3ZHKJ7+MRy/xSZ1JlOmAGOZrOhkcjcAiezoqKDyjQPpAfBSdV3FSnM7p9h8QhlBcpAYg7CW2/xr1VQXU4dMuOx14l39zdNX74HT2DcpZkvuB3T6pDpCxPlfDaFWg2pE0nkQI4IX25lL3B8UmTDy2Q= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=OSsj8klbgUey+PDhoUPYj4aNxmaDA7OOswmCJjcmXxPE1HTxiCk2RXkXZbReZlfWbckCHsVM85bhIBpOImZct4e/irSqCsWqnQiMZRq7UJ5S4MOXJ3GeqIkT+u9KsaO7Zrbs5Oq8HysScoFmWZLjkuW0G2pG7v+TawCI0sxafms=; Message-ID: <409567.66527.qm@web111407.mail.gq1.yahoo.com> X-YMail-OSG: uBeAlQwVM1kXA56cm_Vd6H.gsn8XQbrhtiTLcEEIDiKe_YL APKTmTGk5Iryveslx5K_RUs5bcMwwAcQ.eNxN.xniQSoIRC4Mx7gmha10Neb gr8SAGTJvQk18y7_f16YF4wyGpZhgPrfFUD2scwp7UdHxHrpHsJzQF7sy32B xXmDZDKbSpiBud9XxuiZZqylcfMW5FBq.AQnT_y6hX0hG6l8Fna81xia4cJs ffG3zdJclbAqEDuM6PcTPv9xXjjucnBjO8BMOU18f0hPp5GEgc1zeZMud7gj kHFnC3Mfhuggbw_C7pVmHTAfgRR3XMY2KY0ZssSfVfQfBFJZsnobfS7CVHN6 ra7ITv4gF47CAdmht7Bac_2Q9HnfQH9pShCNgcjnjuBhoelbh37Dz_HHq7_Q pnv_3 Received: from [206.16.17.212] by web111407.mail.gq1.yahoo.com via HTTP; Wed, 22 Dec 2010 08:25:44 PST X-Mailer: YahooMailRC/553 YahooMailWebService/0.8.107.285259 References: <283E485E53107A4991ACFBEA65AC1A860805D354@xmb-sjc-22e.amer.cisco.com> Date: Wed, 22 Dec 2010 08:25:44 -0800 (PST) From: Behcet Sarikaya To: "Stephan Millet \(stmillet\)" , Cameron Byrne , behave@ietf.org In-Reply-To: <283E485E53107A4991ACFBEA65AC1A860805D354@xmb-sjc-22e.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [BEHAVE] ULA as PREF64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 16:23:49 -0000 > > My 2c worth, > > Using ULAs will not allow your DNS64 to resolve using IPv6 as a > transport when talking to IPv6 enabled root servers or other IPv6 > enabled authoritative servers. This maybe true for standard servers. But here we are talking about DNS64 server which should be configurable by the operator to use ULA prefixes. > > If I can go slightly off topic, given that the NAT64 prefix is unique to > your network This is not necessarily correct. An operator may use more than one NAT64 prefixes and NAT64 servers. > how could it be used by people outside your administrative > domain ? Other users could point their DNS queries to your DNS64, though > when crap answers get returned, that behaviour should stop relatively > quickly. (I am differentiating here between a DOS attack versus a > misconfigured resolver) > Regards, Behcet From dthaler@microsoft.com Wed Dec 22 08:38:11 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75F103A6B2A; Wed, 22 Dec 2010 08:38:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.242 X-Spam-Level: X-Spam-Status: No, score=-110.242 tagged_above=-999 required=5 tests=[AWL=-0.243, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95+LUc2Y8d+E; Wed, 22 Dec 2010 08:38:10 -0800 (PST) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 435F03A6A67; Wed, 22 Dec 2010 08:38:10 -0800 (PST) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 22 Dec 2010 08:40:08 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.1.255.3; Wed, 22 Dec 2010 08:40:08 -0800 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.151]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Wed, 22 Dec 2010 08:40:08 -0800 From: Dave Thaler To: Iljitsch van Beijnum Thread-Topic: [BEHAVE] one week WGLC, draft-ietf-behave-ftp64-05 Thread-Index: ActY6jKKLqeAf6WHSOikuiNZqgewtAH/d6IwBraFzQAJXXikgAAN1huAACguIwAABqYt8A== Date: Wed, 22 Dec 2010 16:40:06 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653447F40D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <0cac01cb58ea$32d19a60$9874cf20$@com> <9B57C850BB53634CACEC56EF4853FF65343005F2@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447D195@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447ECAF@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <8B73074C-5B7E-425F-B8B2-C28757FB7CD6@muada.com> In-Reply-To: <8B73074C-5B7E-425F-B8B2-C28757FB7CD6@muada.com> 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 Cc: "draft-ietf-behave-ftp64@tools.ietf.org" , "ftpext@ietf.org" , Behave WG Subject: Re: [BEHAVE] one week WGLC, draft-ietf-behave-ftp64-05 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 16:38:11 -0000 > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > Sent: Wednesday, December 22, 2010 3:41 AM > To: Dave Thaler > Cc: draft-ietf-behave-ftp64@tools.ietf.org; Behave WG; ftpext@ietf.org > Subject: Re: [BEHAVE] one week WGLC, draft-ietf-behave-ftp64-05 >=20 > [CC to ftpext, please prune as desired when following up] >=20 > On 22 dec 2010, at 1:32, Dave Thaler wrote: >=20 > > To your later question, Microsoft's IIS does support RFC 2640 > > in its FTP server. Microsoft's current FTP clients, on the other hand,= do not > > support RFC 2640. >=20 > And so does ProFTPD. >=20 > I quickly checked maybe a dozen FTP sites. A few of them supported LANG, > although none any languages other than English, one UTF8 but not LANG, on= e > LANG but not FEAT (which is in non-conformance to RFC 2640). So I guess a > quick deprecation is off the table. >=20 > After reading RFC 2640 a bit more closely, it turns out that it actually = allows > CR/LFs in filenames, but those are escaped using a null character. This p= robably > warrants a warning in the FTP64 document, as ALG implementers may not be > aware of this and of course a null character has special meaning in langu= ages > such as C. >=20 > Back to the original problem. >=20 > Ideally, the ALG would observe the LANG negotiation and then send text in= the > desired language. However, there is no way to make sure that the ALG supp= orts > all the languages that clients and servers may support, so even if the AL= G makes > this attempt, there will be cases when it can't provide text in the desir= ed > language. >=20 > When that happens, there are two choices: >=20 > 1. block the LANG negotiation and use the default language >=20 > 2. ignore the LANG negotiation and use the default language Yes for LANG (as opposed to the FEAT exchange), those are the same as I=20 described in my email. > The advantage of 1 is consistency. However, this is more complex to imple= ment > and despite some evidence of LANG support I fear that actual use of this = feature > is too low to see good real-world testing, so there is a significant risk= of bugs > that won't come to light until the ALG is widely deployed. Another downsi= de is > that the user is now deprived of text in the desired language for text se= nt by the > server that isn't touched by the ALG. Most notably, this would be the gre= etings. > With failed LANG negotiation, users probably also wouldn't be able to use= UTF-8 > user names, passwords or path names. The last sentence is not correct. The LANG command only controls the lang= uage of the server's text responses. It has no effect on the ability for the cl= ient (or server) to use UTF-8 user names, passwords, or path names. But yes, the advantage is consistency, and the disadvantage is that you're limited to languages supported by both the server and the ALG. >=20 > The advantage of 2 is implementation simplicity and that the majority of = the text > is still in the desired language. However, some server responses will be = in the > ALG's (default) language rather than in the negotiated language. (But inf= ormed > users can still see what's going on from the numeric response, the text i= s merely > additional information.) To repeat my earlier point, the disadvantages are 1) Text from the ALG may render as garbage (even overwriting the numeric re= sponse, making it impossible for the user to see what's going on... remember som= e languages are bidirectional so this isn't just about the backspace character) 2) Some clients might even crash or have other unexpected behavior, since 2 appears to violate RFC 2640 and hence could easily have untested beha= vior. To me, the above disadvantages are strong arguments against 2. >=20 > I propose the following: >=20 > - provide some explanation of the issue in the document > - ALGs MUST support UTF-8 and the CR0LF thing > - ALGs MAY monitor the LANG negotiation and adjust their language accordi= ngly > (with no opinion about what happens when the ALG supports the user desire= d > language but the server doesn't) Personally, I think the above MAY needs to be a MUST. > - if the ALG doesn't monitor the LANG negotiation or doesn't support the > negotiated language, it uses its default language >=20 > Thoughts? -Dave From dthaler@microsoft.com Wed Dec 22 09:17:12 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B75B43A67FD; Wed, 22 Dec 2010 09:17:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.539 X-Spam-Level: X-Spam-Status: No, score=-110.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNEFBSKZ-A9w; Wed, 22 Dec 2010 09:17:11 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id D6AC83A6B30; Wed, 22 Dec 2010 09:17:11 -0800 (PST) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 22 Dec 2010 09:19:10 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.1.255.3; Wed, 22 Dec 2010 09:19:09 -0800 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.151]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Wed, 22 Dec 2010 09:19:09 -0800 From: Dave Thaler To: Dave Thaler , Iljitsch van Beijnum Thread-Topic: [BEHAVE] one week WGLC, draft-ietf-behave-ftp64-05 Thread-Index: ActY6jKKLqeAf6WHSOikuiNZqgewtAH/d6IwBraFzQAJXXikgAAN1huAACguIwAABqYt8AALsh7Q Date: Wed, 22 Dec 2010 17:19:08 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653447F599@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <0cac01cb58ea$32d19a60$9874cf20$@com> <9B57C850BB53634CACEC56EF4853FF65343005F2@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447D195@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447ECAF@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <8B73074C-5B7E-425F-B8B2-C28757FB7CD6@muada.com> <9B57C850BB53634CACEC56EF4853FF653447F40D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653447F40D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> 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 Cc: "draft-ietf-behave-ftp64@tools.ietf.org" , "ftpext@ietf.org" , Behave WG Subject: Re: [BEHAVE] one week WGLC, draft-ietf-behave-ftp64-05 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 17:17:12 -0000 One more comment... [...] > > Ideally, the ALG would observe the LANG negotiation and then send text > > in the desired language. However, there is no way to make sure that > > the ALG supports all the languages that clients and servers may > > support, so even if the ALG makes this attempt, there will be cases > > when it can't provide text in the desired language. > > > > When that happens, there are two choices: > > > > 1. block the LANG negotiation and use the default language > > > > 2. ignore the LANG negotiation and use the default language >=20 > Yes for LANG (as opposed to the FEAT exchange), those are the same as I > described in my email. >=20 > > The advantage of 1 is consistency. However, this is more complex to > > implement and despite some evidence of LANG support I fear that actual > > use of this feature is too low to see good real-world testing, so > > there is a significant risk of bugs that won't come to light until the > > ALG is widely deployed. Another downside is that the user is now > > deprived of text in the desired language for text sent by the server th= at isn't > touched by the ALG. Most notably, this would be the greetings. > > With failed LANG negotiation, users probably also wouldn't be able to > > use UTF-8 user names, passwords or path names. >=20 > The last sentence is not correct. The LANG command only controls the > language > of the server's text responses. It has no effect on the ability for the = client (or > server) to use UTF-8 user names, passwords, or path names. >=20 > But yes, the advantage is consistency, and the disadvantage is that you'r= e > limited to languages supported by both the server and the ALG. >=20 > > > > The advantage of 2 is implementation simplicity and that the majority > > of the text is still in the desired language. However, some server > > responses will be in the ALG's (default) language rather than in the > > negotiated language. (But informed users can still see what's going on > > from the numeric response, the text is merely additional information.) >=20 > To repeat my earlier point, the disadvantages are > 1) Text from the ALG may render as garbage (even overwriting the numeric > response, > making it impossible for the user to see what's going on... remember s= ome > languages > are bidirectional so this isn't just about the backspace character) > 2) Some clients might even crash or have other unexpected behavior, since > 2 appears to violate RFC 2640 and hence could easily have untested be= havior. >=20 > To me, the above disadvantages are strong arguments against 2. Of course, in theory, neither of the above *should* be a problem=20 if implementations deal with text correctly. I guess the main point is about RFC compliance and levels of testing. I wouldn't want to apparently violate RFC 2640 without the=20 FTPEXT group's consent, so that would be the question to the FTPEXT list. -Dave=20 From dwing@cisco.com Wed Dec 22 11:35:55 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 913313A68A5 for ; Wed, 22 Dec 2010 11:35:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.504 X-Spam-Level: X-Spam-Status: No, score=-110.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4myh1F0EmNS5 for ; Wed, 22 Dec 2010 11:35:54 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 86B793A685B for ; Wed, 22 Dec 2010 11:35:53 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUFAN7iEU2rR7Ht/2dsb2JhbACWBoEljHRzqCSbSYVJBIRm X-IronPort-AV: E=Sophos;i="4.60,214,1291593600"; d="scan'208";a="393592430" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 22 Dec 2010 19:37:49 +0000 Received: from dwingWS (sjc-vpn6-1217.cisco.com [10.21.124.193]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oBMJbnlU015176 for ; Wed, 22 Dec 2010 19:37:49 GMT From: "Dan Wing" To: Date: Wed, 22 Dec 2010 11:37:49 -0800 Message-ID: <01db01cba20f$b738e740$25aab5c0$@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: AcuiD7cAYJihzgVHQqWCPobGyEFUVw== Content-Language: en-us Subject: [BEHAVE] milestone: analysis of NAT-PT considerations X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 19:35:55 -0000 The document draft-penno-behave-64-analysis is the most likely candidate to meet BEHAVE's milestone "Feb 2011 - Submit to IESG: Analysis of NAT-PT considerations with IPv6/IPv4 translation (info)". However, we would like feedback from the working group, especially around the desired scope of the document. http://tools.ietf.org/html/draft-penno-behave-64-analysis-05 Abstract: Due to specific problems, NAT-PT was deprecated by the IETF as a mechanism to perform IPv6-IPv4 translation. Since then, new efforts have been undertaken within IETF to standardize alternative mechanisms to perform IPv6-IPv4 translation. This document evaluates how the new translation mechanisms avoid the problems that caused the IETF to deprecate NAT-PT. ToC: 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Context . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Analysis of 64 Translation Against Concerns of RFC4966 . . . . 4 2.1. Problems Not Addressed by 64 . . . . . . . . . . . . . . . 4 2.2. Problems Addressed by 64 . . . . . . . . . . . . . . . . . 7 2.3. Problems Addressed by NAT44 Translation Documents . . . . 8 3. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 9 At IETF79, we asked two questions of the room but received no useful feedback. We hope to receive more feedback on the mailing list. The questions were: 1. Open Question #1 The current version covers Stateful NAT64 only Shall we extend the document to Stateless NAT64? 2. Open Question #2 No recommendation is provided in the I-D as we want the document to be analysis document and avoid solution-related discussion. Does the WG agree with this scope? At IETF79, Jari Arkko made the following comment regarding the document: The document classifies things into issues that have not been addressed and issues that have been addressed elsewhere. Would be better to classifies things into issues that can be addressed, and what is impossible to fix. If anyone has guidance / suggestions for scope of the document, or how it might be best organized, the authors and chairs would certainly appreciate that feedback. Thanks, -d From dwing@cisco.com Thu Dec 23 10:04:37 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D7063A6856; Thu, 23 Dec 2010 10:04:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.512 X-Spam-Level: X-Spam-Status: No, score=-110.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0tt0sfHNKVxh; Thu, 23 Dec 2010 10:04:35 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 81FDC3A6850; Thu, 23 Dec 2010 10:04:35 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAN8dE02rR7H+/2dsb2JhbACXN4x0c6Vnmy6FSgSEZQ X-IronPort-AV: E=Sophos;i="4.60,219,1291593600"; d="scan'208";a="640611294" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 23 Dec 2010 18:06:36 +0000 Received: from dwingWS (sjc-vpn2-687.cisco.com [10.21.114.175]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oBNI6ajr022399; Thu, 23 Dec 2010 18:06:36 GMT From: "Dan Wing" To: "'Dave Thaler'" , "'Iljitsch van Beijnum'" References: <0cac01cb58ea$32d19a60$9874cf20$@com> <9B57C850BB53634CACEC56EF4853FF65343005F2@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447D195@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447ECAF@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <8B73074C-5B7E-425F-B8B2-C28757FB7CD6@muada.com> <9B57C850BB53634CACEC56EF4853FF653447F40D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447F599@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653447F599@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Date: Thu, 23 Dec 2010 10:06:36 -0800 Message-ID: <049901cba2cc$238f67e0$6aae37a0$@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: ActY6jKKLqeAf6WHSOikuiNZqgewtAH/d6IwBraFzQAJXXikgAAN1huAACguIwAABqYt8AALsh7QABxF4tA= Content-Language: en-us Cc: draft-ietf-behave-ftp64@tools.ietf.org, ftpext@ietf.org, 'Behave WG' Subject: Re: [BEHAVE] one week WGLC, draft-ietf-behave-ftp64-05 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2010 18:04:37 -0000 This thread underscores why standardizing an ALGs is terribly difficult. In this case, the addition of a new feature (LANG command) on the client and server requires the ALG to either break that new feature or to fully support the new feature. For the ALG to fully support LANG, that means an ALG has to support all possible languages that can be expressed by LANG. ... and, remember, FTP is a "simple" protocol. The best solution I see is the FTP64 ALG has to (MUST) remove LANG from the server's FEAT response, and translate the LANG command to NOOP and return a 5xy response to the client. If an FTP client, running on an IPv6-only machine, does not like LANG being disabled, there are two solutions: 1. the FTP client has to implement the "ALGS DISABLE64" command, and ensure the IPv4-only FTP server it is using properly supports the EPSV command. This is, effectively, draft-ietf-ftpext2-ftp64-00. OR 2. have the FTP server add an AAAA record, and properly support the EPSV command. This causes the FTP traffic to not use the NAT64 or FTP64 ALG. -d > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Dave Thaler > Sent: Wednesday, December 22, 2010 9:19 AM > To: Dave Thaler; Iljitsch van Beijnum > Cc: draft-ietf-behave-ftp64@tools.ietf.org; ftpext@ietf.org; Behave WG > Subject: Re: [BEHAVE] one week WGLC, draft-ietf-behave-ftp64-05 > > One more comment... > > [...] > > > Ideally, the ALG would observe the LANG negotiation and then send > text > > > in the desired language. However, there is no way to make sure that > > > the ALG supports all the languages that clients and servers may > > > support, so even if the ALG makes this attempt, there will be cases > > > when it can't provide text in the desired language. > > > > > > When that happens, there are two choices: > > > > > > 1. block the LANG negotiation and use the default language > > > > > > 2. ignore the LANG negotiation and use the default language > > > > Yes for LANG (as opposed to the FEAT exchange), those are the same as > I > > described in my email. > > > > > The advantage of 1 is consistency. However, this is more complex to > > > implement and despite some evidence of LANG support I fear that > actual > > > use of this feature is too low to see good real-world testing, so > > > there is a significant risk of bugs that won't come to light until > the > > > ALG is widely deployed. Another downside is that the user is now > > > deprived of text in the desired language for text sent by the > server that isn't > > touched by the ALG. Most notably, this would be the greetings. > > > With failed LANG negotiation, users probably also wouldn't be able > to > > > use UTF-8 user names, passwords or path names. > > > > The last sentence is not correct. The LANG command only controls > the > > language > > of the server's text responses. It has no effect on the ability for > the client (or > > server) to use UTF-8 user names, passwords, or path names. > > > > But yes, the advantage is consistency, and the disadvantage is that > you're > > limited to languages supported by both the server and the ALG. > > > > > > > > The advantage of 2 is implementation simplicity and that the > majority > > > of the text is still in the desired language. However, some server > > > responses will be in the ALG's (default) language rather than in > the > > > negotiated language. (But informed users can still see what's going > on > > > from the numeric response, the text is merely additional > information.) > > > > To repeat my earlier point, the disadvantages are > > 1) Text from the ALG may render as garbage (even overwriting the > numeric > > response, > > making it impossible for the user to see what's going on... > remember some > > languages > > are bidirectional so this isn't just about the backspace > character) > > 2) Some clients might even crash or have other unexpected behavior, > since > > 2 appears to violate RFC 2640 and hence could easily have > untested behavior. > > > > To me, the above disadvantages are strong arguments against 2. > > Of course, in theory, neither of the above *should* be a problem > if implementations deal with text correctly. I guess the main point > is about RFC compliance and levels of testing. > > I wouldn't want to apparently violate RFC 2640 without the > FTPEXT group's consent, so that would be the question to the FTPEXT > list. > > -Dave > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From iljitsch@muada.com Thu Dec 23 10:11:17 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AFA13A6855; Thu, 23 Dec 2010 10:11:11 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iydbjXllAOlB; Thu, 23 Dec 2010 10:11:07 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 483AD3A685A; Thu, 23 Dec 2010 10:11:03 -0800 (PST) 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 oBNICvC3072895 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 23 Dec 2010 19:12:57 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: <049901cba2cc$238f67e0$6aae37a0$@com> Date: Thu, 23 Dec 2010 19:12:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <101F87C4-F714-48C2-852A-67332B712DD1@muada.com> References: <0cac01cb58ea$32d19a60$9874cf20$@com> <9B57C850BB53634CACEC56EF4853FF65343005F2@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447D195@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447ECAF@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <8B73074C-5B7E-425F-B8B2-C28757FB7CD6@muada.com> <9B57C850BB53634CACEC56EF4853FF653447F40D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447F599@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <049901cba2cc$238f67e0$6aae37a0$@com> To: "Dan Wing" X-Mailer: Apple Mail (2.1082) Cc: draft-ietf-behave-ftp64@tools.ietf.org, ftpext@ietf.org, 'Behave WG' , 'Dave Thaler' Subject: Re: [BEHAVE] one week WGLC, draft-ietf-behave-ftp64-05 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2010 18:11:17 -0000 On 23 dec 2010, at 19:06, Dan Wing wrote: > The best solution I see is the FTP64 ALG has to (MUST)=20 > remove LANG from the server's FEAT response, and translate > the LANG command to NOOP and return a 5xy response to the > client. But how does making the server use the default language make the user's = experience any better?= From dwing@cisco.com Thu Dec 23 10:25:01 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43FF53A6858; Thu, 23 Dec 2010 10:25:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.514 X-Spam-Level: X-Spam-Status: No, score=-110.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gy4a6TGCz06L; Thu, 23 Dec 2010 10:25:00 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 726F03A6843; Thu, 23 Dec 2010 10:25:00 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFABciE02rR7Hu/2dsb2JhbACXN4x0c6VcmyuFSgSEZQ X-IronPort-AV: E=Sophos;i="4.60,219,1291593600"; d="scan'208";a="237095583" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 23 Dec 2010 18:27:01 +0000 Received: from dwingWS (sjc-vpn2-687.cisco.com [10.21.114.175]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id oBNIR1ee012334; Thu, 23 Dec 2010 18:27:01 GMT From: "Dan Wing" To: "'Iljitsch van Beijnum'" References: <0cac01cb58ea$32d19a60$9874cf20$@com> <9B57C850BB53634CACEC56EF4853FF65343005F2@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447D195@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447ECAF@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <8B73074C-5B7E-425F-B8B2-C28757FB7CD6@muada.com> <9B57C850BB53634CACEC56EF4853FF653447F40D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447F599@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <049901cba2cc$238f67e0$6aae37a0$@com> <101F87C4-F714-48C2-852A-67332B712DD1@muada.com> In-Reply-To: <101F87C4-F714-48C2-852A-67332B712DD1@muada.com> Date: Thu, 23 Dec 2010 10:27:01 -0800 Message-ID: <04a401cba2ce$fdba5180$f92ef480$@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: AcuizQsxEH0fsv7gT0CgDu564FTndQAABOLw Content-Language: en-us Cc: draft-ietf-behave-ftp64@tools.ietf.org, ftpext@ietf.org, 'Behave WG' , 'Dave Thaler' Subject: Re: [BEHAVE] one week WGLC, draft-ietf-behave-ftp64-05 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2010 18:25:01 -0000 > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > Sent: Thursday, December 23, 2010 10:13 AM > To: Dan Wing > Cc: 'Dave Thaler'; draft-ietf-behave-ftp64@tools.ietf.org; > ftpext@ietf.org; 'Behave WG' > Subject: Re: [BEHAVE] one week WGLC, draft-ietf-behave-ftp64-05 > > On 23 dec 2010, at 19:06, Dan Wing wrote: > > > The best solution I see is the FTP64 ALG has to (MUST) > > remove LANG from the server's FEAT response, and translate > > the LANG command to NOOP and return a 5xy response to the > > client. > > But how does making the server use the default language make the user's > experience any better? The user might have to read something in the FTP server's default language, but it will be ASCII. That's better than the FTP client potentially throwing an error. -d From iljitsch@muada.com Thu Dec 23 13:41:34 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B46DA3A68B7; Thu, 23 Dec 2010 13:41:34 -0800 (PST) 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=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8OyXFcjZ5mXP; Thu, 23 Dec 2010 13:40:59 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id B17343A6895; Thu, 23 Dec 2010 13:40:58 -0800 (PST) Received: from [192.168.0.195] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id oBNLgpE5073861 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 23 Dec 2010 22:42:52 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: <04a401cba2ce$fdba5180$f92ef480$@com> Date: Thu, 23 Dec 2010 22:42:48 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0cac01cb58ea$32d19a60$9874cf20$@com> <9B57C850BB53634CACEC56EF4853FF65343005F2@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447D195@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447ECAF@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <8B73074C-5B7E-425F-B8B2-C28757FB7CD6@muada.com> <9B57C850BB53634CACEC56EF4853FF653447F40D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447F599@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <049901cba2cc$238f67e0$6aae37a0$@com> <101F87C4-F714-48C2-852A-67332B712DD1@muada.com> <04a401cba2ce$fdba5180$f92ef480$@com> To: Dan Wing X-Mailer: Apple Mail (2.1082) Cc: draft-ietf-behave-ftp64@tools.ietf.org, ftpext@ietf.org, 'Behave WG' , 'Dave Thaler' Subject: Re: [BEHAVE] one week WGLC, draft-ietf-behave-ftp64-05 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2010 21:41:35 -0000 On 23 dec 2010, at 19:27, Dan Wing wrote: >> But how does making the server use the default language make the = user's >> experience any better? > The user might have to read something in the FTP server's default > language, but it will be ASCII. That's better than the FTP client > potentially throwing an error. Dave mentioned the client potentially crashing. I don't buy that. An FTP = client can obviously handle ASCII if the desired LANG is not supported, = so then it's going to crash when it sees the same characters when = another language is negotiated but it otherwise sees the same text. It's = not like 7-bit ASCII characters never occur in languages that use other = scripts. Maybe at this point in the discussion it would be good to hear from = implementers. There are already tons of NAT44 FTP ALGs out there, I = wonder how those solve this.= From Internet-Drafts@ietf.org Thu Dec 30 04:00:03 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28B003A676A; Thu, 30 Dec 2010 04:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.477 X-Spam-Level: X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGMAHLCxT1q9; Thu, 30 Dec 2010 04:00:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52D1D3A6778; Thu, 30 Dec 2010 04:00:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20101230120002.20554.83192.idtracker@localhost> Date: Thu, 30 Dec 2010 04:00:02 -0800 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-sctpnat-04.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2010 12:00:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : Stream Control Transmission Protocol (SCTP) Network Address Translation Author(s) : R. Stewart, et al. Filename : draft-ietf-behave-sctpnat-04.txt Pages : 26 Date : 2010-12-30 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-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-behave-sctpnat-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-12-30035829.I-D@ietf.org> --NextPart--