From iljitsch@muada.com Mon May 2 05:26:27 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD7EE0819 for ; Mon, 2 May 2011 05:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.374 X-Spam-Level: X-Spam-Status: No, score=-102.374 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, SARE_SUB_ENC_UTF8=0.152, 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 SVHYHTj57g9q for ; Mon, 2 May 2011 05:26:26 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id 65BE5E0812 for ; Mon, 2 May 2011 05:26:26 -0700 (PDT) Received: from [IPv6:2001:470:1f0b:1289:223:12ff:fe56:36b2] ([IPv6:2001:470:1f0b:1289:223:12ff:fe56:36b2]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id p42CRb96079195 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 2 May 2011 14:27:38 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Iljitsch van Beijnum In-Reply-To: <4DB95962.5090407@gmail.com> Date: Mon, 2 May 2011 14:26:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DB95962.5090407@gmail.com> To: buptnoc X-Mailer: Apple Mail (2.1084) Cc: behave@ietf.org Subject: Re: [BEHAVE] =?utf-8?q?***SPAM***_5=2E548_=285=29_Is_nat46_worth_rese?= =?utf-8?q?arching=EF=BC=9F?= 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, 02 May 2011 12:26:27 -0000 On 28 apr 2011, at 14:11, buptnoc wrote: > As described in draft-ietf-behave-v6v4-framework-10#section-2.4 = =EF=BC=8C we need nat46 translator.=20 > But, do we really need this scenario=EF=BC=9FIs it worth to deploy = this scenario? > In fact, this scenario appears when we have v4-only client and = v6-only servers My opinion is: no, this is not worth the trouble. We know that NAT46 is = a hard problem, and it's unlikely a solution would be very robust. = Because of lack of IPv4 addresses, a relatively small pool of v4 = addresses would have to map to all possible v6 addresses, which means = that the mappings have to be highly dynamic. But addresses are cached in = many places, including often for a long time in applications. Having = different applications react differently to NAT46 would be a big = deployment problem. I would recommend (apart from upgrading to IPv6) deploying HTTP and = HTTPS proxies, as those will allow HTTP and HTTPS from IPv4-only clients = to IPv6-only servers (or the other way around!) and in principle, it's = possible to modify any TCP-based application to work through an HTTPS = proxy, as those are basically TCP relays. It should be possible to make an automatic proxy configuration so that a = browser only uses the proxy to reach IPv6 destinations and connects to = IPv4 destinations directly. However, I haven't tried this myself yet. From behcetsarikaya@yahoo.com Mon May 2 08:18:09 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29F0FE069B for ; Mon, 2 May 2011 08:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.023 X-Spam-Level: X-Spam-Status: No, score=-2.023 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] 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 rrgddhaZppD9 for ; Mon, 2 May 2011 08:18:08 -0700 (PDT) Received: from nm23-vm0.bullet.mail.sp2.yahoo.com (nm23-vm0.bullet.mail.sp2.yahoo.com [98.139.91.224]) by ietfa.amsl.com (Postfix) with SMTP id 91F2FE0675 for ; Mon, 2 May 2011 08:18:08 -0700 (PDT) Received: from [98.139.91.62] by nm23.bullet.mail.sp2.yahoo.com with NNFMP; 02 May 2011 15:18:08 -0000 Received: from [98.139.91.16] by tm2.bullet.mail.sp2.yahoo.com with NNFMP; 02 May 2011 15:18:08 -0000 Received: from [127.0.0.1] by omp1016.mail.sp2.yahoo.com with NNFMP; 02 May 2011 15:18:08 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 515557.21401.bm@omp1016.mail.sp2.yahoo.com Received: (qmail 66071 invoked by uid 60001); 2 May 2011 15:18:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1304349488; bh=AB0bmy9g9Oww5w7+KAmvXrynpF8+q7S5YpInNJZ3CHc=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=mwUVMOeSp2yRZb6vTH4Xa3iEX2d7elsNp8BTLUs6NL6eLk0BO0XYl9V5uvZ0uGFyTiFifl8sZvXuTMhds2i+FTQ97Ky23UowrtTP8iZf9yCgJuumnyv89MfPLJzlI4xroQOd64NNHThSajo2Cij/EQYRF+fw6hpm1hASktOsrfc= 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:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=agjIKtXgesKRd/Kb89xirexsbpRGbqVP94CDa2D15d/huyIAndLzL8ande73YTA0LOi7CbpWZ0zlCvQ+4gfA2e0swAj1gSlzoBo0JKwe/jKMUJxY2x2BVju4zKMWK7F07nwPu1txXWZHznP6H6Kon+kmGAYVKIGCykSesBY8RH8=; Message-ID: <192669.64705.qm@web111411.mail.gq1.yahoo.com> X-YMail-OSG: ilHuOiwVM1kozxmbgfpRp4M2fZ5zcl7liKHhWXwwP.5C8xH ShhzN8Ha9l0ZjIYCbYsQFHN6VLXOmNkvIVPdElQSVHhdAJBbYo1.9PzOIpT8 pSKdlpXj05M_BVP7huNNHAOjkfcSRg3P9cewdsSsi37UvwmRKjskVJ4_XR02 y9CE_PtrUYrBPumYJbFOtrxjpSU7aFK9WcShGT.nFW.0wbJczU5qqa2s6gr7 uq3KH8UBbgbCEYwGJiuUipQc7TT9AzSNebI4F8Nx3A9WGQUkR.r1EjdXdT6X tlBUAWUfXTsmc4ufwuWK4JjRHdT3AC06z5GsOM8Fyw3s9_gtpQQ8O8a5E8JC Eiczz2mbMBOtyWzKpb7DhGl7tYl08_FhYdQaW7Pd4YVkYz85z9StYfKbfbtz sslIqCSt7SAkTovCas4xFEEKhMU2jqgaUFrpMvdmy2w-- Received: from [206.16.17.212] by web111411.mail.gq1.yahoo.com via HTTP; Mon, 02 May 2011 08:18:08 PDT X-Mailer: YahooMailRC/559 YahooMailWebService/0.8.110.299900 References: <4DB95962.5090407@gmail.com> Date: Mon, 2 May 2011 08:18:08 -0700 (PDT) From: Behcet Sarikaya To: Iljitsch van Beijnum , buptnoc In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: softwires@ietf.org, behave@ietf.org Subject: Re: [BEHAVE] =?utf-8?q?***SPAM***_5=2E548_=285=29_Is_nat46_worth_rese?= =?utf-8?q?arching=EF=BC=9F?= X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 15:18:09 -0000 This is good point.=0ABut maybe this should be discussed in Softwires list.= =0A=0ARegards,=0A=0ABehcet=0A=0A> On 28 apr 2011, at 14:11, buptnoc wrote:= =0A=0A> =0A> > As described in draft-ietf-behave-v6v4-framework-10#sec= tion-2.4 =EF=BC=8C we =0A>need nat46 translator. =0A>=0A> > But, do we = really need this scenario=EF=BC=9FIs it worth to deploy this =0A>scenario?= =0A> =0A> > In fact, this scenario appears when we have v4-only client= and v6-only =0A>servers=0A> =0A> My opinion is: no, this is not worth the= trouble. We know that NAT46 is a hard =0A>problem, and it's unlikely a so= lution would be very robust. Because of lack of =0A>IPv4 addresses, a rela= tively small pool of v4 addresses would have to map to =0A>all possible v6 = addresses, which means that the mappings have to be highly =0A>dynamic. Bu= t addresses are cached in many places, including often for a long =0A>time= in applications. Having different applications react differently to NAT46= =0A>would be a big deployment problem.=0A> =0A> I would recommend (apart = from upgrading to IPv6) deploying HTTP and HTTPS =0A>proxies, as those wil= l allow HTTP and HTTPS from IPv4-only clients to IPv6-only =0A>servers (or= the other way around!) and in principle, it's possible to modify =0A>any = TCP-based application to work through an HTTPS proxy, as those are =0A>bas= ically TCP relays.=0A> =0A> It should be possible to make an automatic pro= xy configuration so that a =0A>browser only uses the proxy to reach IPv6 d= estinations and connects to IPv4 =0A>destinations directly. However, I hav= en't tried this myself yet.=0A> =0A> =0A> ________________________________= _______________=0A> Behave mailing list=0A> Behave@ietf.org=0A> https://ww= w.ietf.org/mailman/listinfo/behave=0A> From stephan.lagerholm@secure64.com Mon May 2 09:31:28 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 8A14CE0764 for ; Mon, 2 May 2011 09:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.007 X-Spam-Level: X-Spam-Status: No, score=0.007 tagged_above=-999 required=5 tests=[AWL=0.502, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.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 YL1JnNn6IS3i for ; Mon, 2 May 2011 09:31:27 -0700 (PDT) Received: from zimbra.secure64.com (unknown [64.92.221.189]) by ietfa.amsl.com (Postfix) with ESMTP id 66FDEE0760 for ; Mon, 2 May 2011 09:31:16 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.secure64.com (Postfix) with ESMTP id BC2D1B8395 for ; Mon, 2 May 2011 10:23:23 -0600 (MDT) X-Virus-Scanned: amavisd-new at secure64.com Received: from zimbra.secure64.com ([127.0.0.1]) by localhost (zimbra.secure64.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQONKwEHapwA; Mon, 2 May 2011 10:23:22 -0600 (MDT) Received: from exchange.secure64.com (exchange.secure64.com [192.168.254.250]) by zimbra.secure64.com (Postfix) with ESMTPSA id 72D79B8391 for ; Mon, 2 May 2011 10:23:22 -0600 (MDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=secure64.com; s=2010; t=1304353402; bh=9/opRCvMbzCZMfDASHX8cbKR+XDzmjf9fvDJFgduefE=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:Subject:Date: Message-ID:In-Reply-To:References:From:To; b=oA92pB7BZHlOaKcc7br71 fipMGP32oO3j0FTyncsMDzUMbWqpJtx9llSuRk/kWp4jL77hxBOc+PxlR0F9Yy5grs1 WotgjHucwUl427Bb2Lj3vjRlJxdCd+51ZuczHI7cixsASRwCiAU+zlDbG+JGEmi4hPI cMDuv38snzMgZnAI= 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: Mon, 2 May 2011 10:17:11 -0600 Message-ID: In-Reply-To: <4DBA1B45.2060906@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 6147 section 5.1.4 help. Thread-Index: AcwGDyJhGr1+jahsToCeklcnMD2FogC1sMRQ References: <4DBA1B45.2060906@gmail.com> From: "Stephan Lagerholm" To: Subject: [BEHAVE] RFC 6147 section 5.1.4 help. 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, 02 May 2011 16:31:28 -0000 I need advise on RFC 6147 section 5.1.4, The RFC says that: "A DNS64 implementation SHOULD provide a mechanism to specify IPv6 prefix ranges to be treated as though the AAAA containing them were an empty answer." But then a few sentences later it says that: "When the DNS64 performs its initial AAAA query, if it receives an answer with only AAAA records containing addresses in the excluded range(s), then it MUST treat the answer as though it were an empty answer, and proceed accordingly." How should that be interpreted? 1. A DNS64 solution SHOULD provide a mechanism to exclude certain ranges of IPv6 addresses. 2. A DNS64 solution MUST provide a mechanism to exclude certain ranges of IPv6 addresses. 3. If a DNS64 solution provides a mechanism to exclude certain ranges, then it MUST treat the answer as empty. But if it doesn't provide a mechanism, then it doesn't have to treat the answer as empty. Thanks, Stephan ---------------------------------------------------------------------- Stephan Lagerholm Senior DNS Architect, M.Sc. ,CISSP Secure64 Software Corporation, www.secure64.com Cell: 469-834-3940 From iljitsch@muada.com Mon May 2 09:37:53 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 5B7BDE06CB; Mon, 2 May 2011 09:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.342 X-Spam-Level: X-Spam-Status: No, score=-102.342 tagged_above=-999 required=5 tests=[AWL=-0.194, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, SARE_SUB_ENC_UTF8=0.152, 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 XNl6cu2YJpmi; Mon, 2 May 2011 09:37:52 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4D5E067E; Mon, 2 May 2011 09:37:52 -0700 (PDT) Received: from [IPv6:2001:470:1f0b:1289:223:12ff:fe56:36b2] ([IPv6:2001:470:1f0b:1289:223:12ff:fe56:36b2]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id p42Gd2Rb080781 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 2 May 2011 18:39:04 +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: <192669.64705.qm@web111411.mail.gq1.yahoo.com> Date: Mon, 2 May 2011 18:37:43 +0200 Content-Transfer-Encoding: 7bit Message-Id: <6941A4D4-9744-441E-9FE9-D7C4A591109E@muada.com> References: <4DB95962.5090407@gmail.com> <192669.64705.qm@web111411.mail.gq1.yahoo.com> To: Behcet Sarikaya X-Mailer: Apple Mail (2.1084) Cc: softwires@ietf.org, buptnoc , behave@ietf.org Subject: Re: [BEHAVE] =?utf-8?q?***SPAM***_5=2E548_=285=29_Is_nat46_worth_rese?= =?utf-8?q?arching=EF=BC=9F?= 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, 02 May 2011 16:37:53 -0000 On 2 mei 2011, at 17:18, Behcet Sarikaya wrote: > This is good point. > But maybe this should be discussed in Softwires list. Is softwires doing anything related to NAT46 then? From cb.list6@gmail.com Mon May 2 10:21:56 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2A8EE077E for ; Mon, 2 May 2011 10:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.64 X-Spam-Level: X-Spam-Status: No, score=-2.64 tagged_above=-999 required=5 tests=[AWL=0.507, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] 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 I8fMFiy7LaTH for ; Mon, 2 May 2011 10:21:56 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id D43DCE06B1 for ; Mon, 2 May 2011 10:21:55 -0700 (PDT) Received: by ewy19 with SMTP id 19so2213088ewy.31 for ; Mon, 02 May 2011 10:21:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=kCYQkpnJHQhrdbfGZf4IB1/LXrX1lV8cOfIdUoUm5MA=; b=CZFEP1ZISpkuOgdFfzQfIVsaGDGyw2aSDWCGWzY/kg0pXDWhOIru6Jl+eQXvK0eOXz oGQDOV9F4fVj0oLAVFcwd6+a52IKHJ4iFvFZ3DeLjG8a2a68TWzm5hn/77/pMRNGomjZ vPoy4s077WyehcbP2cb2eD/KuQCr2XOs2Tbys= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=cg5f7BueMjViomKvI5QZvgl5kRJtEw6xvIWlICz4gGnFRm1waln1be2+nYBWIDc2hL 836s77gJr8a7Kk0gRxI2JyBA8GrFUQh+MNgWEzei//NU2rWLXv7Z4J/y6UNKhCZMxj7s X2KwF360uypc5YvIka8Xod8WuA8OjHo++DhC4= MIME-Version: 1.0 Received: by 10.14.127.76 with SMTP id c52mr1528262eei.57.1304356914701; Mon, 02 May 2011 10:21:54 -0700 (PDT) Received: by 10.14.45.80 with HTTP; Mon, 2 May 2011 10:21:54 -0700 (PDT) In-Reply-To: References: <4DB95962.5090407@gmail.com> Date: Mon, 2 May 2011 10:21:54 -0700 Message-ID: From: Cameron Byrne To: Iljitsch van Beijnum Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: buptnoc , behave@ietf.org Subject: Re: [BEHAVE] =?utf-8?q?***SPAM***_5=2E548_=285=29_Is_nat46_worth_rese?= =?utf-8?q?arching=EF=BC=9F?= 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, 02 May 2011 17:21:56 -0000 On Mon, May 2, 2011 at 5:26 AM, Iljitsch van Beijnum w= rote: > On 28 apr 2011, at 14:11, buptnoc wrote: > >> =C2=A0 =C2=A0 As described in draft-ietf-behave-v6v4-framework-10#sectio= n-2.4 =EF=BC=8C we need nat46 translator. >> =C2=A0 =C2=A0 But, do we really need this scenario=EF=BC=9FIs it worth t= o deploy this scenario? > >> =C2=A0 =C2=A0 In fact, this scenario appears when we have v4-only client= and v6-only servers > > My opinion is: no, this is not worth the trouble. We know that NAT46 is a= hard problem, and it's unlikely a solution would be very robust. Because o= f lack of IPv4 addresses, a relatively small pool of v4 addresses would hav= e to map to all possible v6 addresses, which means that the mappings have t= o be highly dynamic. But addresses are cached in many places, including oft= en for a long time in applications. Having different applications react dif= ferently to NAT46 would be a big deployment problem. > I believe NAT46 has a great deal of utility on the end host where an ipv4-only application or ipv4-literal is referenced on a node that only has ipv6 connectivity. This has already been demonstrated here http://code.google.com/p/n900ipv6/wiki/Nat64D Some protocols don't work in the inevitable and required IPv6-only near term future. NAT46 is required to make the NAT464 use case work and thus allows networks operators, especially in mobile, to move forward. > I would recommend (apart from upgrading to IPv6) deploying HTTP and HTTPS= proxies, as those will allow HTTP and HTTPS from IPv4-only clients to IPv6= -only servers (or the other way around!) and in principle, it's possible to= modify any TCP-based application to work through an HTTPS proxy, as those = are basically TCP relays. > Notice that the list of applications that are fixed by the above N900 code are MSN messenger, Skype, as well as ipv4-literals. Cameron > It should be possible to make an automatic proxy configuration so that a = browser only uses the proxy to reach IPv6 destinations and connects to IPv4= destinations directly. However, I haven't tried this myself yet. > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From iljitsch@muada.com Mon May 2 10:29:57 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F04EEE078B for ; Mon, 2 May 2011 10:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.318 X-Spam-Level: X-Spam-Status: No, score=-102.318 tagged_above=-999 required=5 tests=[AWL=-0.169, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, SARE_SUB_ENC_UTF8=0.152, 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 53rWLNEyfwpA for ; Mon, 2 May 2011 10:29: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 E58B2E078A for ; Mon, 2 May 2011 10:29:56 -0700 (PDT) Received: from [IPv6:2001:470:1f0b:1289:223:12ff:fe56:36b2] ([IPv6:2001:470:1f0b:1289:223:12ff:fe56:36b2]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id p42HVAtQ081105 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 2 May 2011 19:31:11 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: Date: Mon, 2 May 2011 19:29:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DB95962.5090407@gmail.com> To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: buptnoc , behave@ietf.org Subject: Re: [BEHAVE] =?utf-8?q?***SPAM***_5=2E548_=285=29_Is_nat46_worth_rese?= =?utf-8?q?arching=EF=BC=9F?= 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, 02 May 2011 17:29:58 -0000 On 2 mei 2011, at 19:21, Cameron Byrne wrote: > I believe NAT46 has a great deal of utility on the end host where an > ipv4-only application or ipv4-literal is referenced on a node that > only has ipv6 connectivity. That's NAT64. NAT46 is when an IPv4-only host wants to go to = ipv6.google.com. > NAT46 is required to make the NAT464 use case work and thus allows > networks operators, especially in mobile, to move forward. If you know that a NAT64 step follows the NAT46 step, you can optimize = away the problem where you need to cram an 128-bit address into a 32-bit = address, so this doesn't really qualify as the general NAT46 case = either. From cb.list6@gmail.com Mon May 2 12:17: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 1E8D0E072E for ; Mon, 2 May 2011 12:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.681 X-Spam-Level: X-Spam-Status: No, score=-2.681 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] 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 RMUh9I8ULj+n for ; Mon, 2 May 2011 12:17:57 -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 4A68EE071E for ; Mon, 2 May 2011 12:17:57 -0700 (PDT) Received: by eye13 with SMTP id 13so2255044eye.31 for ; Mon, 02 May 2011 12:17:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/GaM7BpuKQZohkSmi/NWLARMgTN/N6FJoeoOJ79yFJY=; b=eIr5aVhr6fNnbMxD17gsTzDD97X3lEQ9oFE8yFI72OVqh5XM0fF4lp0vjpqtRwktXL qqQpb7/jGQuPdhXxp9wbMYdx+gAlE2x93R3Bhn63ip3oTX8nt4JYbT342wSZ8EOGyWEj 4v1Vg9W+HDG0kct6c6ea3U3NeMaXGcXaAOn1M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=dNZExR1IqLSVsrWT7dptWrj09Hjm6LqMskySP0u1iOiHuAe3WfXyY2thWTdvRzKCfn Cn32jCVuU4vW/b4dDYnHyvCafY3hZUigyz9emdGy2uDN9lnzp2P/Wrw9Y1M6+itfzHyP PH9wl7d4mp6CHgespOo2vW9U0FrPp0Wjn5vhQ= MIME-Version: 1.0 Received: by 10.14.21.133 with SMTP id r5mr3331656eer.249.1304363876201; Mon, 02 May 2011 12:17:56 -0700 (PDT) Received: by 10.14.45.80 with HTTP; Mon, 2 May 2011 12:17:56 -0700 (PDT) Received: by 10.14.45.80 with HTTP; Mon, 2 May 2011 12:17:56 -0700 (PDT) In-Reply-To: References: <4DB95962.5090407@gmail.com> Date: Mon, 2 May 2011 12:17:56 -0700 Message-ID: From: Cameron Byrne To: Iljitsch van Beijnum Content-Type: multipart/alternative; boundary=0016e65860fa7fb62404a24fe104 Cc: buptnoc , behave@ietf.org Subject: Re: [BEHAVE] =?utf-8?q?***SPAM***_5=2E548_=285=29_Is_nat46_worth_rese?= =?utf-8?q?arching=EF=BC=9F?= 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, 02 May 2011 19:17:58 -0000 --0016e65860fa7fb62404a24fe104 Content-Type: text/plain; charset=ISO-8859-1 On May 2, 2011 10:29 AM, "Iljitsch van Beijnum" wrote: > > On 2 mei 2011, at 19:21, Cameron Byrne wrote: > > > I believe NAT46 has a great deal of utility on the end host where an > > ipv4-only application or ipv4-literal is referenced on a node that > > only has ipv6 connectivity. > > That's NAT64. NAT46 is when an IPv4-only host wants to go to ipv6.google.com. > No, the use case I gave is nat46. An app on a phone that requires ipv4 sockets on a v6 only host. My previous email referenced an implementation of nat46 on the host that works in conjunction with nat64 in my network. It works today for many people as a nat464 Cb > > NAT46 is required to make the NAT464 use case work and thus allows > > networks operators, especially in mobile, to move forward. > > If you know that a NAT64 step follows the NAT46 step, you can optimize away the problem where you need to cram an 128-bit address into a 32-bit address, so this doesn't really qualify as the general NAT46 case either. > --0016e65860fa7fb62404a24fe104 Content-Type: text/html; charset=ISO-8859-1


On May 2, 2011 10:29 AM, "Iljitsch van Beijnum" <iljitsch@muada.com> wrote:
>
> On 2 mei 2011, at 19:21, Cameron Byrne wrote:
>
> > I believe NAT46 has a great deal of utility on the end host where an
> > ipv4-only application or ipv4-literal is referenced on a node that
> > only has ipv6 connectivity.
>
> That's NAT64. NAT46 is when an IPv4-only host wants to go to ipv6.google.com.
>

No, the use case I gave is nat46. An app on a phone that requires ipv4 sockets on a v6 only host. My previous email referenced an implementation of nat46 on the host that works in conjunction with nat64 in my network.

It works today for many people as a nat464

Cb

> > NAT46 is required to make the NAT464 use case work and thus allows
> > networks operators, especially in mobile, to move forward.
>
> If you know that a NAT64 step follows the NAT46 step, you can optimize away the problem where you need to cram an 128-bit address into a 32-bit address, so this doesn't really qualify as the general NAT46 case either.
>

--0016e65860fa7fb62404a24fe104-- From marka@isc.org Mon May 2 17: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 0B898E07E2 for ; Mon, 2 May 2011 17:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[AWL=0.578, 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 ZfX03FJZE+xt for ; Mon, 2 May 2011 17:53:22 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 5B2A6E072D for ; Mon, 2 May 2011 17:53:22 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 30C83C941E; Tue, 3 May 2011 00:53:19 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id B9893216C1E; Tue, 3 May 2011 00:53:18 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 4CC0CE690BF; Tue, 3 May 2011 10:53:36 +1000 (EST) To: "Stephan Lagerholm" From: Mark Andrews References: <4DBA1B45.2060906@gmail.com> In-reply-to: Your message of "Mon, 02 May 2011 10:17:11 CST." Date: Tue, 03 May 2011 10:53:36 +1000 Message-Id: <20110503005336.4CC0CE690BF@drugs.dv.isc.org> Cc: behave@ietf.org Subject: Re: [BEHAVE] RFC 6147 section 5.1.4 help. 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, 03 May 2011 00:53:23 -0000 In message , "Ste phan Lagerholm" writes: > I need advise on RFC 6147 section 5.1.4, > > The RFC says that: > "A DNS64 implementation SHOULD provide a mechanism to specify IPv6 > prefix ranges to be treated as though the AAAA containing them were an > empty answer." > > But then a few sentences later it says that: > "When the DNS64 performs its initial AAAA query, if it receives an > answer with only AAAA records containing addresses in the excluded > range(s), then it MUST treat the answer as though it were an empty > answer, and proceed accordingly." > > How should that be interpreted? > 1. A DNS64 solution SHOULD provide a mechanism to exclude certain ranges > of IPv6 addresses. > 2. A DNS64 solution MUST provide a mechanism to exclude certain ranges > of IPv6 addresses. > 3. If a DNS64 solution provides a mechanism to exclude certain ranges, > then it MUST treat the answer as empty. But if it doesn't provide a > mechanism, then it doesn't have to treat the answer as empty. > > Thanks, Stephan To answer this it is 3. You have yet to get to the bit about not returning excluded addresses even if there are no A records to map which goes way too far. It is not the nameservers job to protect clients from addresses that cannot be reached. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From dwing@cisco.com Mon May 2 22:30:14 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 3E00DE06F1; Mon, 2 May 2011 22:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.233 X-Spam-Level: X-Spam-Status: No, score=-110.233 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, SARE_SUB_ENC_UTF8=0.152, 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 TUQlv-ZCjZWD; Mon, 2 May 2011 22:30:13 -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 35809E069C; Mon, 2 May 2011 22:30:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2613; q=dns/txt; s=iport; t=1304400613; x=1305610213; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=iTM0l96rYG+m3gGEc99R2t8aDOGl6cEPSmIgCR32HG8=; b=BdWoPHyWKBStKd7KJMdiEoXnDAM3wGzv1d8Txh0rzp4AnmOS+xOKoia/ DdtrDDhkYQj2N7++xMWqyzjFV7Doa43B+UxgHay+1ZARQu2fENAQsHSYa b1CWPoU3MHpWXBKl/qtLdnRyz5dMZqvPdBPDtmmau8n9TQLg5beI1hphv s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsBAMORv02rRDoJ/2dsb2JhbACEUZM1gWOMJ3eIcp8qi2WQaoEqg1WBAQSGDpcz X-IronPort-AV: E=Sophos;i="4.64,307,1301875200"; d="scan'208";a="307040752" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 03 May 2011 05:29:17 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p435TH6m007320; Tue, 3 May 2011 05:29:17 GMT From: "Dan Wing" To: "'Behcet Sarikaya'" , "'Iljitsch van Beijnum'" , "'buptnoc'" References: <4DB95962.5090407@gmail.com> <192669.64705.qm@web111411.mail.gq1.yahoo.com> In-Reply-To: <192669.64705.qm@web111411.mail.gq1.yahoo.com> Date: Mon, 2 May 2011 22:29:17 -0700 Message-ID: <01df01cc0953$0c23a560$246af020$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcwI3C+FjgR2wVypQceDg2U5kI+1sQAdXdQw Content-Language: en-us Cc: softwires@ietf.org, behave@ietf.org Subject: Re: [BEHAVE] =?utf-8?q?***SPAM***_5=2E548_=285=29_Is_nat46_worth_rese?= =?utf-8?q?arching=EF=BC=9F?= 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, 03 May 2011 05:30:14 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Behcet Sarikaya > Sent: Monday, May 02, 2011 8:18 AM > To: Iljitsch van Beijnum; buptnoc > Cc: softwires@ietf.org; behave@ietf.org > Subject: Re: [BEHAVE] ***SPAM*** 5.548 (5) Is nat46 worth = researching=EF=BC=9F >=20 > This is good point. > But maybe this should be discussed in Softwires list. NAT46 is in scope of BEHAVE, and is not in scope of SOFTWIRE. The BEHAVE charter is clear on that. But I have not yet understood how or where we would see an IPv4-only client needing to access an IPv6-only server (that is, a server with only an IPv6 address). -d > Regards, >=20 > Behcet >=20 > > On 28 apr 2011, at 14:11, buptnoc wrote: >=20 > > > > > As described in draft-ietf-behave-v6v4-framework-10#section- > 2.4 =EF=BC=8C we > >need nat46 translator. > > > > > But, do we really need this scenario=EF=BC=9FIs it worth to = deploy > this > >scenario? > > > > > In fact, this scenario appears when we have v4-only client = and > v6-only > >servers > > > > My opinion is: no, this is not worth the trouble. We know that = NAT46 > is a hard > >problem, and it's unlikely a solution would be very robust. Because > of lack of > >IPv4 addresses, a relatively small pool of v4 addresses would have = to > map to > >all possible v6 addresses, which means that the mappings have to be > highly > >dynamic. But addresses are cached in many places, including often = for > a long > >time in applications. Having different applications react = differently > to NAT46 > >would be a big deployment problem. > > > > I would recommend (apart from upgrading to IPv6) deploying HTTP and > HTTPS > >proxies, as those will allow HTTP and HTTPS from IPv4-only clients = to > IPv6-only > >servers (or the other way around!) and in principle, it's possible = to > modify > >any TCP-based application to work through an HTTPS proxy, as those > are > >basically TCP relays. > > > > It should be possible to make an automatic proxy configuration so > that a > >browser only uses the proxy to reach IPv6 destinations and connects > to IPv4 > >destinations directly. However, I haven't tried this myself yet. > > > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From iljitsch@muada.com Tue May 3 01:35: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 DD94EE0708 for ; Tue, 3 May 2011 01:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, SARE_SUB_ENC_UTF8=0.152, 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 PAf8TIuy7Tgg for ; Tue, 3 May 2011 01:35: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 12181E071C for ; Tue, 3 May 2011 01:35: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 p438affS087275 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 May 2011 10:36:43 +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: <01df01cc0953$0c23a560$246af020$@com> Date: Tue, 3 May 2011 10:35:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DB95962.5090407@gmail.com> <192669.64705.qm@web111411.mail.gq1.yahoo.com> <01df01cc0953$0c23a560$246af020$@com> To: "Dan Wing" X-Mailer: Apple Mail (2.1084) Cc: "behave@ietf.org WG" Subject: Re: [BEHAVE] =?utf-8?q?Is_nat46_worth_researching=EF=BC=9F?= 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, 03 May 2011 08:35:32 -0000 On 3 mei 2011, at 7:29, Dan Wing wrote: > But I have not yet understood how or where we would see an IPv4-only > client needing to access an IPv6-only server (that is, a server > with only an IPv6 address). Professional content people aren't going to go IPv6-only until it's very = well established that this can be done with a minimal impact on audience = numbers. Considering that they're relucted to go dual stack now this is = going to be a while. But there's more than professional content. People may want to publish = services from their home, which is trivial to do if they have IPv6, = somewhat hard if they run NAT44 and almost impossible in the presence of = NAT444. There's also peer-to-peer, which would be problematic for NAT46 as = applications like BitTorrent can burn through large numbers of = destinations in a short time, potentially exhausting mapping resources. Then again, if an IPv4-only peer and an IPv6-only peer want to talk, = they could also do this through NAT64 initiated from the IPv6 side = rather than NAT46 initiated from the IPv4 side, as with NAT64 the = address mappings (of course not the NAT state) is static and can't be = exhausted. From behcetsarikaya@yahoo.com Tue May 3 09:34:32 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 3C55DE086F for ; Tue, 3 May 2011 09:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.032 X-Spam-Level: X-Spam-Status: No, score=-2.032 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] 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 FBZa-GHQ2g99 for ; Tue, 3 May 2011 09:34:31 -0700 (PDT) Received: from nm12.bullet.mail.sp2.yahoo.com (nm12.bullet.mail.sp2.yahoo.com [98.139.91.82]) by ietfa.amsl.com (Postfix) with SMTP id 57224E06C3 for ; Tue, 3 May 2011 09:34:31 -0700 (PDT) Received: from [98.139.91.61] by nm12.bullet.mail.sp2.yahoo.com with NNFMP; 03 May 2011 16:34:28 -0000 Received: from [98.139.91.56] by tm1.bullet.mail.sp2.yahoo.com with NNFMP; 03 May 2011 16:34:28 -0000 Received: from [127.0.0.1] by omp1056.mail.sp2.yahoo.com with NNFMP; 03 May 2011 16:34:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 830763.29675.bm@omp1056.mail.sp2.yahoo.com Received: (qmail 53214 invoked by uid 60001); 3 May 2011 16:34:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1304440468; bh=V0iGhGm2AT0hUZa4N3454W4rEQRsuxTEWscIFPjqiNA=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=BhfiM4Yg66fbYPgfUsT3K8kTIOS7+JazmwjZ6H7Kuy6naoVhzttyVivfTxueqBWRCUs1iqdQPDy14nyfK7J7TxOJjWTjtCW7YXxseKHskcYK+jJ3oTkuLJca2KkEeexgMh0COtVWEwRR6p5Vu3+h9z1EXcZ14af10hCL5rH2F2c= 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:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=aoevmGyrtQ7E4uIE7oImheL0QExB+qK4fsS7OZZ/trgCa2Lz0HrS42RJpCnnzOPTFlbPYTvh9BjD4ACEZ0ZhcWdCEmDsp+H3X6xYNGxSqf4ftIc3XmMbUxJGFOSAsiSHiSUUltx4pnrdHEJCgbdcLRxNrCNyq2IGt3AC1e1cayY=; Message-ID: <440994.52878.qm@web111411.mail.gq1.yahoo.com> X-YMail-OSG: uyXI7kEVM1m42dSNHDPo5Xh8Hfu2FWImXDbEMDgPdTXPEXz vJqLu6Rds8kBrXk0.1swtalXc9dXv5B5HDFebF.pVPYtOqce8_FQahSXKNdC VHKwquEvECGPSHb3u9im0uJVhHbHG9KnvQmY87KKN00jrMu1fiEgU6c3mwfy tTMMIztaF.LU2RR1P8A0CxFRC3E2OwFja5ufUHaa2z3lJyvrZBLKfCYA.Lhl zS2..FzJQo8yZxnu4Mex3YwdE4hfLLU8T9WzJ9JA8rgx63cOw8Tcbj6oiclO iwuCDD5D8Hu95p1PoWq9Ly4TkJi5PIb0WspoCox0KC1gD8QNTbfIAqE7MiJJ diVUa.ry6vSF6592T0OTbWivAZ6KBpjBL06med4.iA1R.1uR5NYE2M3bgcIm Kgrm0_xFbfZZRRR5aE84hhdxH2w5w9O4zdbXo.fdB5aM- Received: from [206.16.17.212] by web111411.mail.gq1.yahoo.com via HTTP; Tue, 03 May 2011 09:34:28 PDT X-Mailer: YahooMailRC/559 YahooMailWebService/0.8.110.299900 References: <4DB95962.5090407@gmail.com> Date: Tue, 3 May 2011 09:34:28 -0700 (PDT) From: Behcet Sarikaya To: Cameron Byrne , Iljitsch van Beijnum In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: buptnoc , behave@ietf.org Subject: Re: [BEHAVE] =?utf-8?q?***SPAM***_5=2E548_=285=29_Is_nat46_worth_rese?= =?utf-8?q?arching=EF=BC=9F?= X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 16:34:32 -0000 I think Cameron is talking about BIH. It is 464 solution on the host. It wo= rks =0Awith NAT64 in the network. Good to run v4-only applications on a hos= t connected =0Ato v6 network.=0A=0A=0A=0A>On May 2, 2011 10:29 AM, "Iljitsc= h van Beijnum" wrote:=0A>>=0A>> On 2 mei 2011, at 19:2= 1, Cameron Byrne wrote:=0A>>=0A>> > I believe NAT46 has a great deal of uti= lity on the end host where an=0A>> > ipv4-only application or ipv4-literal = is referenced on a node that=0A>> > only has ipv6 connectivity.=0A>>=0A>> T= hat's NAT64. NAT46 is when an IPv4-only host wants to go to ipv6.google.com= .=0A>>=0A>No, the use case I gave is nat46. An app on a phone that requires= ipv4 sockets =0A>on a v6 only host. My previous email referenced an implem= entation of nat46 on =0A>the host that works in conjunction with nat64 in m= y network.=0A>It works today for many people as a nat464=0A>Cb=0A>=0A>> > N= AT46 is required to make the NAT464 use case work and thus allows=0A>> > ne= tworks operators, especially in mobile, to move forward.=0A>>=0A>> If you k= now that a NAT64 step follows the NAT46 step, you can optimize away the =0A= >>=0A>>problem where you need to cram an 128-bit address into a 32-bit addr= ess, so this =0A>>=0A>>doesn't really qualify as the general NAT46 case eit= her.=0A>>=0A> From iljitsch@muada.com Tue May 3 10:14:43 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 D425CE0705 for ; Tue, 3 May 2011 10:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.283 X-Spam-Level: X-Spam-Status: No, score=-102.283 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152, 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 VUCSFCz5bLRd for ; Tue, 3 May 2011 10:14:29 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id 61A16E06F8 for ; Tue, 3 May 2011 10:14:29 -0700 (PDT) Received: from claw.it.uc3m.es ([163.117.139.50]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id p43HFdZY090068 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 May 2011 19:15:40 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: Date: Tue, 3 May 2011 19:13:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <63A1BADE-202A-4FCC-BBFB-60C6E67E8D92@muada.com> References: <4DB95962.5090407@gmail.com> To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: buptnoc , behave@ietf.org Subject: Re: [BEHAVE] =?utf-8?q?***SPAM***_5=2E548_=285=29_Is_nat46_worth_rese?= =?utf-8?q?arching=EF=BC=9F?= 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, 03 May 2011 17:14:43 -0000 On 2 mei 2011, at 21:17, Cameron Byrne wrote: > > > I believe NAT46 has a great deal of utility on the end host where = an > > > ipv4-only application or ipv4-literal is referenced on a node that > > > only has ipv6 connectivity. > > That's NAT64. NAT46 is when an IPv4-only host wants to go to = ipv6.google.com. > No, the use case I gave is nat46. An app on a phone that requires ipv4 = sockets on a v6 only host. How is it NAT46 if the ultimate destination is an IPv4 host? Please stick to the terminology. From dwing@cisco.com Tue May 3 10:55: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 E81CEE085E for ; Tue, 3 May 2011 10:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.986 X-Spam-Level: X-Spam-Status: No, score=-106.986 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, RCVD_IN_DNSWL_HI=-8, SARE_SUB_ENC_ISO2022JP=0.413, 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 3kh+QId71Ko0 for ; Tue, 3 May 2011 10:55:27 -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 3679AE085D for ; Tue, 3 May 2011 10:55:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1219; q=dns/txt; s=iport; t=1304445316; x=1305654916; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=oy1wlqghpoRd6RjcvtQ0wKYJBHmy9uVZYHoU+AKdVTk=; b=ZL9KEzT57Rfc1m11byGuuOtvao8O7VygpgYPoFs4g8fZ+hPnKXTw1hcB qjOlzfbrOyfkXExiGsxphw+KoDhbC7GAeEIAfAC9GAK7CJ/V3YpUCE/yA I7pw2SdEWxUHBDtz6/VM8qZ/AHbh5tDKOEYZy2XGKrGk+2AP2vAougC0o 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsBAFxAwE2rRDoG/2dsb2JhbACEUZM3gWOMMXeIcp57i2ABkR+BJ4NXgQQEhiWXRQ X-IronPort-AV: E=Sophos;i="4.64,310,1301875200"; d="scan'208";a="307519402" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-3.cisco.com with ESMTP; 03 May 2011 17:55:15 +0000 Received: from dwingWS (dhcp-171-70-220-136.cisco.com [171.70.220.136]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p43HtFDD023610; Tue, 3 May 2011 17:55:15 GMT From: "Dan Wing" To: "'Iljitsch van Beijnum'" , "'Cameron Byrne'" References: <4DB95962.5090407@gmail.com> <63A1BADE-202A-4FCC-BBFB-60C6E67E8D92@muada.com> In-Reply-To: <63A1BADE-202A-4FCC-BBFB-60C6E67E8D92@muada.com> Date: Tue, 3 May 2011 10:55:15 -0700 Message-ID: <038101cc09bb$41ba6250$c52f26f0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcwJtaKudBOqtjNRQduijv0etlzLmAABR//w Content-Language: en-us Cc: 'buptnoc' , behave@ietf.org Subject: Re: [BEHAVE] =?iso-2022-jp?b?KioqU1BBTSoqKiA1LjU0OCAoNSkgSXMgbmF0NDYg?= =?iso-2022-jp?b?d29ydGggcmVzZWFyY2hpbmcbJEIhKRsoQg==?= 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, 03 May 2011 17:55:38 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Iljitsch van Beijnum > Sent: Tuesday, May 03, 2011 10:14 AM > To: Cameron Byrne > Cc: buptnoc; behave@ietf.org > Subject: Re: [BEHAVE] ***SPAM*** 5.548 (5) Is nat46 worth researching$B!)(B > > On 2 mei 2011, at 21:17, Cameron Byrne wrote: > > > > > I believe NAT46 has a great deal of utility on the end host where > an > > > > ipv4-only application or ipv4-literal is referenced on a node > that > > > > only has ipv6 connectivity. > > > > That's NAT64. NAT46 is when an IPv4-only host wants to go to > ipv6.google.com. > > > No, the use case I gave is nat46. An app on a phone that requires > ipv4 sockets on a v6 only host. > > How is it NAT46 if the ultimate destination is an IPv4 host? It's NAT46 on the handset, and NAT64 in the network, to an IPv4 host. This in a *system* that is NAT464, a.k.a. "PNAT", a.k.a. draft-durand-ngtrans-nat64-nat46, a.k.a. draft-durand-v6ops-natv4v6v4. -d > Please stick to the terminology. > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From iljitsch@muada.com Tue May 3 14:59:11 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A05D1E072A for ; Tue, 3 May 2011 14:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.148 X-Spam-Level: X-Spam-Status: No, score=-102.148 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, SARE_SUB_ENC_UTF8=0.152, 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 h-R-yHXVcvNW for ; Tue, 3 May 2011 14:59:11 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id C82A6E071E for ; Tue, 3 May 2011 14:59:10 -0700 (PDT) Received: from [IPv6:2001:470:1f0b:1289:223:12ff:fe56:36b2] ([IPv6:2001:470:1f0b:1289:223:12ff:fe56:36b2]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id p43M0LXk091621 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 4 May 2011 00:00:22 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: <038101cc09bb$41ba6250$c52f26f0$@com> Date: Tue, 3 May 2011 23:59:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DB95962.5090407@gmail.com> <63A1BADE-202A-4FCC-BBFB-60C6E67E8D92@muada.com> <038101cc09bb$41ba6250$c52f26f0$@com> To: Dan Wing X-Mailer: Apple Mail (2.1084) Cc: 'Cameron Byrne' , 'buptnoc' , behave@ietf.org Subject: Re: [BEHAVE] =?utf-8?q?***SPAM***_5=2E548_=285=29_Is_nat46_worth_rese?= =?utf-8?q?arching=EF=BC=9F?= 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, 03 May 2011 21:59:11 -0000 On 3 mei 2011, at 19:55, Dan Wing wrote: >> How is it NAT46 if the ultimate destination is an IPv4 host? > It's NAT46 on the handset, and NAT64 in the network, to an > IPv4 host. This in a *system* that is NAT464, a.k.a. "PNAT", > a.k.a. draft-durand-ngtrans-nat64-nat46, a.k.a. > draft-durand-v6ops-natv4v6v4. I would greatly prefer it if people would NOT use "NAT46" for the first = half of NAT464, because that IPv4 to IPv6 translation is a simple one, = while the general NAT46 case is much more difficult. We really don't = need that kind of confusion. It took us a dozen emails to sort it out = here where people are knowledgeable, in the real world this type of = sloppy terminology will be a real mess. From dwing@cisco.com Tue May 3 16:57:03 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBEF2E0679 for ; Tue, 3 May 2011 16:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.793 X-Spam-Level: X-Spam-Status: No, score=-108.793 tagged_above=-999 required=5 tests=[AWL=-1.807, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, RCVD_IN_DNSWL_HI=-8, SARE_SUB_ENC_ISO2022JP=0.413, 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 ouj3HbbCbrOu for ; Tue, 3 May 2011 16:57:03 -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 234DAE0674 for ; Tue, 3 May 2011 16:57:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1090; q=dns/txt; s=iport; t=1304467023; x=1305676623; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=s6zbqTBj57M4hzxosQzkWQ5s2xDQ0uQq0rNwNNr3LtQ=; b=Zi2bh3zVISbYXT6rIxWUo8pYwig9fQ+vu/ZF9mecbsEmJpSCfOnliVn+ yjvQzgUAK4n3KL856ctFzqwphra+RvjRmOkNKBMsSChhw5pFNyMkWODQq yiNagDbIo431FzN4oTK6qCzXfcH9eQj0PYL0qIqKlJDn+ePEq9op4KkRc 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai4BAPGVwE2rRDoG/2dsb2JhbACEUZM6gWOMMnenS4x8AZEegSeDV4EEBIYll0U X-IronPort-AV: E=Sophos;i="4.64,312,1301875200"; d="scan'208";a="307750851" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-3.cisco.com with ESMTP; 03 May 2011 23:56:57 +0000 Received: from dwingWS ([128.107.106.72]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p43NuvF1030331; Tue, 3 May 2011 23:56:57 GMT From: "Dan Wing" To: "'Iljitsch van Beijnum'" References: <4DB95962.5090407@gmail.com> <63A1BADE-202A-4FCC-BBFB-60C6E67E8D92@muada.com> <038101cc09bb$41ba6250$c52f26f0$@com> In-Reply-To: Date: Tue, 3 May 2011 16:56:57 -0700 Message-ID: <053501cc09ed$c91f90d0$5b5eb270$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcwJ3VXerHeRj+PLRJOj/XuJmXyHSAAEGo5g Content-Language: en-us Cc: 'Cameron Byrne' , 'buptnoc' , behave@ietf.org Subject: Re: [BEHAVE] =?iso-2022-jp?b?KioqU1BBTSoqKiA1LjU0OCAoNSkgSXMgbmF0NDYg?= =?iso-2022-jp?b?d29ydGggcmVzZWFyY2hpbmcbJEIhKRsoQg==?= 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, 03 May 2011 23:57:04 -0000 > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > Sent: Tuesday, May 03, 2011 2:59 PM > To: Dan Wing > Cc: 'Cameron Byrne'; 'buptnoc'; behave@ietf.org > Subject: Re: [BEHAVE] ***SPAM*** 5.548 (5) Is nat46 worth researching$B!)(B > > On 3 mei 2011, at 19:55, Dan Wing wrote: > > >> How is it NAT46 if the ultimate destination is an IPv4 host? > > > It's NAT46 on the handset, and NAT64 in the network, to an > > IPv4 host. This in a *system* that is NAT464, a.k.a. "PNAT", > > a.k.a. draft-durand-ngtrans-nat64-nat46, a.k.a. > > draft-durand-v6ops-natv4v6v4. > > I would greatly prefer it if people would NOT use "NAT46" for the first > half of NAT464, because that IPv4 to IPv6 translation is a simple one, > while the general NAT46 case is much more difficult. We really don't > need that kind of confusion. It took us a dozen emails to sort it out > here where people are knowledgeable, in the real world this type of > sloppy terminology will be a real mess. In a host, it's called BIH, draft-ietf-behave-v4v6-bih. -d From prondou@gmail.com Tue May 3 17:26: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 BADF6E0618 for ; Tue, 3 May 2011 17:26:51 -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 TMSeiR933hRb for ; Tue, 3 May 2011 17:26:51 -0700 (PDT) Received: from mailrelay007.isp.belgacom.be (mailrelay007.isp.belgacom.be [195.238.6.173]) by ietfa.amsl.com (Postfix) with ESMTP id 2C915E06CE for ; Tue, 3 May 2011 17:26:43 -0700 (PDT) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApEBAHScwE1R94UK/2dsb2JhbAAM3CmHSTSIY4YCBI8YjX81 Received: from 10.133-247-81.adsl-dyn.isp.belgacom.be (HELO [192.168.1.40]) ([81.247.133.10]) by relay.skynet.be with ESMTP; 04 May 2011 02:26:41 +0200 Message-ID: <4DC09D48.7040604@gmail.com> Date: Wed, 04 May 2011 02:26:48 +0200 From: Pierre Rondou User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: Xing Li , "Rajiv Asati (rajiva)" , behave@ietf.org, draft-xli-behave-ivi@tools.ietf.org, Xing Li References: <067E6CE33034954AAC05C9EC85E2577C0463368C@XMB-RCD-111.cisco.com> <4D7CCD65.7070504@cernet.edu.cn> In-Reply-To: <4D7CCD65.7070504@cernet.edu.cn> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Cyril Soldani , evyncke@cisco.com, guy.leduc@ulg.ac.be Subject: Re: [BEHAVE] draft-xli-behave-ivi -- Error per SIIT ! 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, 04 May 2011 00:26:51 -0000 Hello, Shouldn't those modifications be applied to the web document? Neither the draft document on the IETF website (http://datatracker.ietf.org/doc/draft-xli-behave-ivi/) nor the RFC queued document (http://www.rfc-editor.org/internet-drafts/draft-xli-behave-ivi-07.txt) are updated. Plus, may I suggest to update all references to the old RFC 2765 to the new RFC 6145? RFC 6145 obsoletes RFC 2765. Regards, Pierre RONDOU Le 13/03/11 14:57, Xing Li a écrit : > Another typing error in the previous mail. It should be > > ------------------------------------------------------------- > IPv4 Field Translated to IPv6 > ------------------------------------------------------------- > Version (0x4) Version (0x6) > IHL discarded > Type of Service copied from the IPv6 Traffic Class > Total Length Payload Length = Total Length - 20 > Identification discarded > Flags discarded > Offset discarded > Time to Live Hop Limit > Protocol Next Header > Header Checksum discarded > Source Address IVI address mapping > Destination Address IVI address mapping > Options discarded > ------------------------------------------------------------- > > Figure 6: IPv4 to IPv6 Header translation > > > ------------------------------------------------------------- > IPv6 Field Translated to IPv4 Header > ------------------------------------------------------------- > Version (0x6) Version (0x4) > Traffic Class copied from IP Type Of Service and Precedence field > Flow Label discarded > Payload Length Total Length = Payload Length + 20 > Next Header Protocol > Hop Limit TTL > Source Address IVI address mapping > Destination Address IVI address mapping > - IHL = 5 > - Header Checksum recalculated > ------------------------------------------------------------- > > Figure 7: IPv6 to IPv4 Header translation > > Regards, > > xing > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From buptnoc@gmail.com Tue May 3 19:45:33 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46F32E0679 for ; Tue, 3 May 2011 19:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[AWL=3.136, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] 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 OYsGbElD9Z9S for ; Tue, 3 May 2011 19:45:32 -0700 (PDT) Received: from mail-px0-f170.google.com (mail-px0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id CF6EDE0664 for ; Tue, 3 May 2011 19:45:32 -0700 (PDT) Received: by pxi19 with SMTP id 19so1101937pxi.15 for ; Tue, 03 May 2011 19:45:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=6+M9RT5Dir51eFNrjf2CJ5la0LkNzlGLMn2bemD0uyw=; b=iDsiw36wiV4cbnctjYTBpHYbl2aRILsmYV21JweEzpqffUUYFCXyOQqTKuV3WAOWlI LlKWVMzsRiGF1T93E3dblYfaoU6xTr/DhcYBjRJsHr1W+HyA6uWQc/9gHiZWThErfWFu RE7xOt6GCEKGE9DuLXfLlGv0HokquUQ/tst1Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=uNI/nCCm6ZTTQ9nKzcrT2mGTAOLeN5YL6cGaJ6HgOp/18xhyupT9pgHxNLUcYtK0md 6qQyqCxDxoFAQhjJqwPYmodd4FNhsyrYyAp3/lgkK9QiEjdwTv0n7Uuuu+c4irwZrJUR RRKc5rh7tiqSVXCv1e06j70PD7Dteiub0fCIc= Received: by 10.68.69.105 with SMTP id d9mr762386pbu.455.1304477132369; Tue, 03 May 2011 19:45:32 -0700 (PDT) Received: from [210.25.132.207] ([210.25.132.207]) by mx.google.com with ESMTPS id c10sm424381pbi.67.2011.05.03.19.45.29 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 May 2011 19:45:31 -0700 (PDT) Message-ID: <4DC0BDC5.8070402@gmail.com> Date: Wed, 04 May 2011 10:45:25 +0800 From: buptnoc User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Dan Wing References: <4DB95962.5090407@gmail.com> <192669.64705.qm@web111411.mail.gq1.yahoo.com> <01df01cc0953$0c23a560$246af020$@com> In-Reply-To: <01df01cc0953$0c23a560$246af020$@com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: behave@ietf.org Subject: Re: [BEHAVE] =?utf-8?q?***SPAM***_5=2E548_=285=29_Is_nat46_worth_rese?= =?utf-8?q?arching=EF=BC=9F?= 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, 04 May 2011 02:45:33 -0000 In my opinion, NAT46 is a network-side translation technology , need no modification to host's protocol stack and only does translation once . Other technology involved host-side translation or twice translation such as BIH\PNAT is applied in different scenarios with NAT46. NAT46 has a little difficulty to implement. But now I mainly want to know whether it makes sense to research or deploy NAT46. I think NAT46 depend on the emerging IPv6-only server, but does ISP or ICP need IPv6-only server considering the shortage of IPv4? 于 2011-5-3 13:29, Dan Wing 写é“: >> -----Original Message----- >> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On >> Behalf Of Behcet Sarikaya >> Sent: Monday, May 02, 2011 8:18 AM >> To: Iljitsch van Beijnum; buptnoc >> Cc: softwires@ietf.org; behave@ietf.org >> Subject: Re: [BEHAVE] ***SPAM*** 5.548 (5) Is nat46 worth researching？ >> >> This is good point. >> But maybe this should be discussed in Softwires list. > NAT46 is in scope of BEHAVE, and is not in scope of SOFTWIRE. The > BEHAVE charter is clear on that. > > But I have not yet understood how or where we would see an IPv4-only > client needing to access an IPv6-only server (that is, a server > with only an IPv6 address). > > -d From dwing@cisco.com Tue May 3 23:44: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 7A2C4E072B for ; Tue, 3 May 2011 23:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.646 X-Spam-Level: X-Spam-Status: No, score=-108.646 tagged_above=-999 required=5 tests=[AWL=-1.660, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, RCVD_IN_DNSWL_HI=-8, SARE_SUB_ENC_ISO2022JP=0.413, 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 zpHoVNPX31uz for ; Tue, 3 May 2011 23:44:35 -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 BF857E0720 for ; Tue, 3 May 2011 23:44:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2380; q=dns/txt; s=iport; t=1304491475; x=1305701075; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=1KcmrLbibyvTqmyetmoN06Y3m5neTwAq0PO783FYEFs=; b=PZlebPPVV7tUrxpv2CulT3ww2fXoiG6tWHokTuSykLBafCfXOFLp6E7t vWU20TXS5sZbm+94r4S2AHzqW8gHfmjbQ30ZwqhXG9KW3rkQ2gP5BJbjp wPqMgWpPSddgCdx6UapuTMbVmD2U9UOM+ekYBr/BOsBmbHRiK7sHZI2eq 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkYBAFH1wE2rRDoG/2dsb2JhbACEUJM5gWOMNneIcp1RjHwBkRmBJ4NcgQQEhi2XWQ X-IronPort-AV: E=Sophos;i="4.64,313,1301875200"; d="scan'208";a="691560125" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-6.cisco.com with ESMTP; 04 May 2011 06:44:35 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p446iZgL023091; Wed, 4 May 2011 06:44:35 GMT From: "Dan Wing" To: "'Iljitsch van Beijnum'" References: <4DB95962.5090407@gmail.com> <192669.64705.qm@web111411.mail.gq1.yahoo.com> <01df01cc0953$0c23a560$246af020$@com> In-Reply-To: Date: Tue, 3 May 2011 23:44:35 -0700 Message-ID: <05e901cc0a26$bb518a60$31f49f20$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcwJbREbsjVAujl+SYWTs1+noKZaigAt/vEQ Content-Language: en-us Cc: behave@ietf.org Subject: Re: [BEHAVE] =?iso-2022-jp?b?SXMgbmF0NDYgd29ydGggcmVzZWFyY2hpbmc=?= =?iso-2022-jp?b?GyRCISkbKEI=?= 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, 04 May 2011 06:44:36 -0000 > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > Sent: Tuesday, May 03, 2011 1:35 AM > To: Dan Wing > Cc: behave@ietf.org WG > Subject: Re: Is nat46 worth researching$B!)(B > > On 3 mei 2011, at 7:29, Dan Wing wrote: > > > But I have not yet understood how or where we would see an IPv4-only > > client needing to access an IPv6-only server (that is, a server > > with only an IPv6 address). > > Professional content people aren't going to go IPv6-only until it's > very well established that this can be done with a minimal impact on > audience numbers. Considering that they're relucted to go dual stack > now this is going to be a while. > > But there's more than professional content. People may want to publish > services from their home, which is trivial to do if they have IPv6, > somewhat hard if they run NAT44 and almost impossible in the presence > of NAT444. The question boils down to: When there is IPv6-only content that needs to be accessed by IPv4-only users, is the burden ("incentive") on the IPv4-only user, or is the burden ("incentive") on the IPv6-only user. > There's also peer-to-peer, which would be problematic for NAT46 as > applications like BitTorrent can burn through large numbers of > destinations in a short time, potentially exhausting mapping resources. To date, all the NAT46 solutions I have seen require the client to do a DNS "A" query. But peer to peer applications don't do DNS "A" queries because they don't need to (they use IPv4 addresses), there is no benefit to using DNS names, and because the peers don't have DNS names or don't know their DNS names. So, if NAT46 systems continue to rely in DNS "A" queries, and we want/need peer to peer to work, something needs to change. > Then again, if an IPv4-only peer and an IPv6-only peer want to talk, > they could also do this through NAT64 initiated from the IPv6 side > rather than NAT46 initiated from the IPv4 side, as with NAT64 the > address mappings (of course not the NAT state) is static and can't be > exhausted. They could, but that requires a rendezvous system such as bittorrent's, SIP's, XMPP's, or something else (e.g., Apple's Back-to-my-Mac service and system) to signal "I want to connect to the server" so that the server makes a connection back to you. -d From xing@cernet.edu.cn Wed May 4 03:45:17 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75C70E071F for ; Wed, 4 May 2011 03:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.903 X-Spam-Level: X-Spam-Status: No, score=-99.903 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HAS_XAIMC=2.696, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2asbrU0S-yxU for ; Wed, 4 May 2011 03:45:16 -0700 (PDT) Received: from cernet.edu.cn (cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with SMTP id F2BE6E070D for ; Wed, 4 May 2011 03:45:13 -0700 (PDT) Received: from [127.0.0.1]([202.38.102.1]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm1b4dc15972; Wed, 04 May 2011 18:44:50 +0800 Message-ID: <4DC12E1E.40901@cernet.edu.cn> Date: Wed, 04 May 2011 18:44:46 +0800 From: Xing Li User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; zh-CN; rv:1.9.2.14) Gecko/20110221 Thunderbird/3.1.8 MIME-Version: 1.0 To: Pierre Rondou References: <067E6CE33034954AAC05C9EC85E2577C0463368C@XMB-RCD-111.cisco.com> <4D7CCD65.7070504@cernet.edu.cn> <4DC09D48.7040604@gmail.com> In-Reply-To: <4DC09D48.7040604@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: qna99R0B Cc: behave@ietf.org, draft-xli-behave-ivi@tools.ietf.org, Xing Li , Cyril Soldani , guy.leduc@ulg.ac.be, evyncke@cisco.com, "Rajiv Asati \(rajiva\)" Subject: Re: [BEHAVE] draft-xli-behave-ivi -- Error per SIIT ! 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, 04 May 2011 10:45:17 -0000 Hi, Pierre, Thanks for your mail. 于 2011/5/4 8:26, Pierre Rondou 写é“: > Hello, > > Shouldn't those modifications be applied to the web document? > > Neither the draft document on the IETF website > (http://datatracker.ietf.org/doc/draft-xli-behave-ivi/) nor the RFC > queued document > (http://www.rfc-editor.org/internet-drafts/draft-xli-behave-ivi-07.txt) are > updated. The updated version was in RFC Editor's homepage duing the editing process, not in http://datatracker.ietf.org/doc/draft-xli-behave-ivi/ It is published, https://datatracker.ietf.org/doc/rfc6219/ > > Plus, may I suggest to update all references to the old RFC 2765 to > the new RFC 6145? RFC 6145 obsoletes RFC 2765. It clearly states The IVI is an early design deployed in the CERNET for the stateless translation. The IETF standard IPv4-IPv6 stateless and stateful translation mechanisms are defined in [RFC6144], [RFC6052], [RFC6145], [RFC6146], and [RFC6147]. Regards, xing > > Regards, > > Pierre RONDOU > > > Le 13/03/11 14:57, Xing Li a écrit : >> Another typing error in the previous mail. It should be >> >> ------------------------------------------------------------- >> IPv4 Field Translated to IPv6 >> ------------------------------------------------------------- >> Version (0x4) Version (0x6) >> IHL discarded >> Type of Service copied from the IPv6 Traffic Class >> Total Length Payload Length = Total Length - 20 >> Identification discarded >> Flags discarded >> Offset discarded >> Time to Live Hop Limit >> Protocol Next Header >> Header Checksum discarded >> Source Address IVI address mapping >> Destination Address IVI address mapping >> Options discarded >> ------------------------------------------------------------- >> >> Figure 6: IPv4 to IPv6 Header translation >> >> >> ------------------------------------------------------------- >> IPv6 Field Translated to IPv4 Header >> ------------------------------------------------------------- >> Version (0x6) Version (0x4) >> Traffic Class copied from IP Type Of Service and Precedence field >> Flow Label discarded >> Payload Length Total Length = Payload Length + 20 >> Next Header Protocol >> Hop Limit TTL >> Source Address IVI address mapping >> Destination Address IVI address mapping >> - IHL = 5 >> - Header Checksum recalculated >> ------------------------------------------------------------- >> >> Figure 7: IPv6 to IPv4 Header translation >> >> Regards, >> >> xing >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave > > From Internet-Drafts@ietf.org Wed May 4 09:45: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 57218E0794; Wed, 4 May 2011 09:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, 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 EV9EeWbkKcEH; Wed, 4 May 2011 09:45:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCC67E07A0; Wed, 4 May 2011 09:45:01 -0700 (PDT) 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.53 Message-ID: <20110504164501.7641.26275.idtracker@ietfa.amsl.com> Date: Wed, 04 May 2011 09:45:01 -0700 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-64-analysis-02.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 16:45:02 -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 : Analysis of 64 Translation Author(s) : R. Penno, et al. Filename : draft-ietf-behave-64-analysis-02.txt Pages : 15 Date : 2011-05-04 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-64-analysis-02.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-64-analysis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-04094333.I-D@ietf.org> --NextPart-- From dwing@cisco.com Wed May 4 10:49:44 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D63DBE079C for ; Wed, 4 May 2011 10:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.334 X-Spam-Level: X-Spam-Status: No, score=-110.334 tagged_above=-999 required=5 tests=[AWL=0.265, 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 IMHvmRWauI3R for ; Wed, 4 May 2011 10:49:43 -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 D78FAE0735 for ; Wed, 4 May 2011 10:49:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=415; q=dns/txt; s=iport; t=1304531383; x=1305740983; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=JASkmqSFg0A1T03LILOHMifL455iZRCII2Z1yxTmnrk=; b=J3AxNmBLkiy5ofE0Kalwe+s46ptboWfiZvdB1Xbb51ATxx2gJ1CT3aIJ NDisnbp/cZzJO+w/T6NInmFVvMtZcWFfSi8noqrsIixO9U+Ea1AkYVvai 9zdBKaXN7kuSYVTzoMkaorEGlvaajbSFJbz/f0vUV2ElSS3M7YPBqxtgz g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am4IAC6RwU2rRDoG/2dsb2JhbACYS4EkjC13pmmeOYYHBIYvl2A X-IronPort-AV: E=Sophos;i="4.64,315,1301875200"; d="scan'208";a="350366036" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 04 May 2011 17:49:43 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p44Hnh2O019957; Wed, 4 May 2011 17:49:43 GMT From: "Dan Wing" To: Date: Wed, 4 May 2011 10:49:43 -0700 Message-ID: <088001cc0a83$a65edc90$f31c95b0$@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: AcwKg6YXXDlIudc2QWynU53BkX7fUw== Content-Language: en-us Cc: draft-ietf-behave-64-analysis@tools.ietf.org, 'Behave Chairs' Subject: [BEHAVE] WGLC, draft-ietf-behave-64-analysis-02 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 17:49:44 -0000 We are starting a two week WGLC for "Analysis of 64 Translation", http://www.ietf.org/id/draft-ietf-behave-64-analysis-02.txt, to fulfill BEHAVE's milestone "Feb 2011 - Submit to IESG: Analysis of NAT-PT considerations with IPv6/IPv4 translation (info)". Please send substantive comments to the list, and if possible send editing suggestions just to the authors. The WGLC ends on Wednesday, May 18. -d From prondou@gmail.com Wed May 4 18:18:11 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF09BE0670; Wed, 4 May 2011 18:18:11 -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 83qH2yW-FJxg; Wed, 4 May 2011 18:18:09 -0700 (PDT) Received: from mailrelay004.isp.belgacom.be (mailrelay004.isp.belgacom.be [195.238.6.170]) by ietfa.amsl.com (Postfix) with ESMTP id BCF02E0669; Wed, 4 May 2011 18:18:08 -0700 (PDT) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApEBAHn5wU1XQqnI/2dsb2JhbAAM3hGHTTSIY4YHBI81jjw Received: from 200.169-66-87.adsl-dyn.isp.belgacom.be (HELO [192.168.1.40]) ([87.66.169.200]) by relay.skynet.be with ESMTP; 05 May 2011 03:18:04 +0200 Message-ID: <4DC1FACC.4080204@gmail.com> Date: Thu, 05 May 2011 03:18:04 +0200 From: Pierre Rondou User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: behave@ietf.org, v6ops@ietf.org, netfilter-devel@vger.kernel.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Cyril Soldani , evyncke@cisco.com, guy.leduc@ulg.ac.be Subject: [BEHAVE] Netfilter Module for NAT IVI available 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, 05 May 2011 01:18:11 -0000 Hello everybody, I'm currently a student at the University of Liège. As part of my master thesis, I have to develop a Linux kernel module for IVI ( http://datatracker.ietf.org/doc/rfc6219/ ). I now consider my module as finished (i.e, all functionalities are implemented) and publish it. It is available on sourceforge: http://sourceforge.net/projects/nativi/ Feel free to test it and report to me any bug, bad implementation, error, ... If you believe that this module can be included is the Linux Kernel or in the Xtables-addons framework, I'll be glad and will help you in this task. I have tested my module inside the Xtables-addons framework (version 1.32) on a debian squeeze (6.0.1) linux with a 2.6.32-5 kernel (i686). Because of the lack of "EXPORT_SYMBOL" in the kernel, I had to copy-paste several functions from the kernel into the nativi_kernel_code.c file in order to use some features already available in the kernel (ip_finish_output, ip6_output, icmp_send). Documentation is provided in the source code, if you have any question don't hesitate to ask me. Regards, Pierre RONDOU From xing@cernet.edu.cn Wed May 4 23:45: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 3056CE06AF for ; Wed, 4 May 2011 23:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.903 X-Spam-Level: X-Spam-Status: No, score=-99.903 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eq-pYJKke4vY for ; Wed, 4 May 2011 23:45:53 -0700 (PDT) Received: from cernet.edu.cn (mail.cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with SMTP id 0A6E9E069F for ; Wed, 4 May 2011 23:45:50 -0700 (PDT) Received: from [127.0.0.1]([59.66.24.70]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm104dc272dd; Thu, 05 May 2011 14:45:33 +0800 Message-ID: <4DC2478A.2060709@cernet.edu.cn> Date: Thu, 05 May 2011 14:45:30 +0800 From: Xing Li User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; zh-CN; rv:1.9.2.14) Gecko/20110221 Thunderbird/3.1.8 MIME-Version: 1.0 To: Dan Wing References: <088001cc0a83$a65edc90$f31c95b0$@com> In-Reply-To: <088001cc0a83$a65edc90$f31c95b0$@com> Content-Type: multipart/alternative; boundary="------------080000010905090106020200" X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: qS9TsR0B Cc: draft-ietf-behave-64-analysis@tools.ietf.org, behave@ietf.org, 'Behave Chairs' Subject: Re: [BEHAVE] WGLC, draft-ietf-behave-64-analysis-02 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 06:45:55 -0000 This is a multi-part message in MIME format. --------------080000010905090106020200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit ? 2011/5/5 1:49, Dan Wing ??: > We are starting a two week WGLC for "Analysis of 64 Translation", > http://www.ietf.org/id/draft-ietf-behave-64-analysis-02.txt, to fulfill > BEHAVE's milestone "Feb 2011 - Submit to IESG: Analysis of NAT-PT > considerations with IPv6/IPv4 translation (info)". Please send substantive > comments to the list, and if possible send editing suggestions just to the > authors. > > The WGLC ends on Wednesday, May 18. Since this document clearly states: The scope of this document does not include stateless translation. I suggest to put word "stateful" in the title of this document (as well as in the abstract). Ttile: Analysis of Stateful 64 Translation ^^^^^^^ 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 stateful translation mechanisms avoid the problems that caused the ^^^^^^^ IETF to deprecate NAT-PT. RFC6145 is also part of the stateful translation standards, please cite that RFC in Section 1.1. Regards, xing > -d > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > --------------080000010905090106020200 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 于 2011/5/5 1:49, Dan Wing 写道: 
We are starting a two week WGLC for "Analysis of 64 Translation",
http://www.ietf.org/id/draft-ietf-behave-64-analysis-02.txt, to fulfill
BEHAVE's milestone "Feb 2011 - Submit to IESG: Analysis of NAT-PT
considerations with IPv6/IPv4 translation (info)".  Please send substantive
comments to the list, and if possible send editing suggestions just to the
authors.

The WGLC ends on Wednesday, May 18.

Since this document clearly states:

   The scope of this document does not include stateless translation.

I suggest to put word "stateful" in the title of this document (as well as in the abstract).

Ttile:  Analysis of Stateful 64 Translation
                              ^^^^^^^
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 stateful translation mechanisms avoid the problems that caused the
                          ^^^^^^^
   IETF to deprecate NAT-PT.

RFC6145 is also part of the stateful translation standards, please cite that RFC in Section 1.1.

Regards,

xing


-d


_______________________________________________
Behave mailing list
Behave@ietf.org
https://www.ietf.org/mailman/listinfo/behave

--------------080000010905090106020200-- From dwing@cisco.com Thu May 5 18:10:05 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 036DBE067C for ; Thu, 5 May 2011 18:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.381 X-Spam-Level: X-Spam-Status: No, score=-110.381 tagged_above=-999 required=5 tests=[AWL=0.218, 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 q+MWyDY+TWQC for ; Thu, 5 May 2011 18:10:02 -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 C0065E0663 for ; Thu, 5 May 2011 18:10:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2224; q=dns/txt; s=iport; t=1304644201; x=1305853801; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=XjSASndMGbtmrfBAtTDk4OB6ndYgVFjLl8f26b6ALWs=; b=YLPcj/6WnWHjXL9i2pTH5M4PRM5msZ8MZUsiEWSMqkXo1pI5UeeeN3qt 9gePhI8EuMPttvQHFR+m5UKPDIjrwHYsb3YtVbTSVSzEKji1OxHy/x4Nq BXN9QdOu2j488aF/w+/KV1AqnCgp1Ek1oUxICuvNJwX6CAw0CxqRYgpxs A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AncIAFRJw02rRDoH/2dsb2JhbACYWYEkjEJ3p0WeH4YHBIY4mAE X-IronPort-AV: E=Sophos;i="4.64,323,1301875200"; d="scan'208";a="309538608" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-3.cisco.com with ESMTP; 06 May 2011 01:10:01 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p461A1wA001249; Fri, 6 May 2011 01:10:01 GMT From: "Dan Wing" To: Date: Thu, 5 May 2011 18:10:01 -0700 Message-ID: <035a01cc0b8a$5311ce50$f9356af0$@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: AcwLilLIKIq2VwJWRF2byj3d5YbRHQ== Content-Language: en-us Cc: jouni.nospam@gmail.com, behave-chairs@tools.ietf.org Subject: [BEHAVE] adoption of learn analysis and DNS-based NAT64 prefix discovery 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, 06 May 2011 01:10:05 -0000 At IETF80, we appeared to have reach regarding BEHAVE's milestone "Apr 2011 - Submit to IESG: avoiding NAT64 with dual-stack host for local networks (std)". Excerpt from the minutes is below. Under this milestone, it seems valuable to publish two documents: one which analyzes the various approaches, and another that details the specific recommended approach. To that end, please provide feedback to behave@ietf.org on adopting the following two documents as working group documents: 1. draft-korhonen-behave-nat64-learn-analysis, to be informational http://tools.ietf.org/html/draft-korhonen-behave-nat64-learn-analysis-02 2. draft-savolainen-heuristic-nat64-discovery, likely to be standards track or possibly informational http://tools.ietf.org/html/draft-savolainen-heuristic-nat64-discovery-01 Thanks, -d ----- http://www.ietf.org/proceedings/80/minutes/behave.txt ... Avoiding NAT64 with dual-stack host for local networks (Jouni Korhonen) draft-korhonen-edns0-synthesis-flag draft-savolainen-heuristic-nat64-discovery draft-korhonen-behave-nat64-learn-analysis milestone date: April 2011 Dan Wing: Should we use DNS well-known-name (hack) or the ENDS0 option (more elegant) Andrew Sullivan: Are there implementations of NAT64 that don't currently implement the ENDS0 option? Mark Andrews: BIND does not currently have the ENDS0 option but could easily add it Andrew Sullivan: Needs to be done quickly Matthew Kaufman: What about client resolver APIs that don't support getting to the EDNS0 option? Stuart Cheshire: What software needs to learn the prefix? Client DNS resolver, or other application software? Dave Thaler: Other application software. Stuart Cheshire: Then the resolver API limitation might be a problem. Andrew Sullivan: Standardizing a DNS well-known-name will be an uphill struggle Andrew Sullivan: We should pick one and do it, not both. Dave Thaler: If DNS well-known-name, we need to decide if it's a single global well-known-name, or per-operator, or per vendor? Matthew Kaufman: This will happen. Better to synthesize locally than to store in the DNS far away. ... From phdgang@gmail.com Fri May 6 03:32:20 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAAC4E0709 for ; Fri, 6 May 2011 03:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.048 X-Spam-Level: X-Spam-Status: No, score=0.048 tagged_above=-999 required=5 tests=[AWL=-3.647, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_GB2312=1.345] 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 9jHriZXLOAUN for ; Fri, 6 May 2011 03:32:20 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 39744E0691 for ; Fri, 6 May 2011 03:32:20 -0700 (PDT) Received: by pwi5 with SMTP id 5so1797597pwi.31 for ; Fri, 06 May 2011 03:32:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=waSJypMkrDTgshTcKPBXXdPGEBoLcmc7OmbJio7cDTw=; b=CieumoUfsL6FDkXyRxcfnaVTWYO/+z6N9m+WyZVIyiQkqKruozgzPj0le4qODiE52y qG62R/qBgsa5oK6suthNTC0W8WQC5ldTddS96QA/q3SrjJhqo/K9RFjgoKv2tI7zmRDc U+7Hy7mGXGdUrUQL+iHBw19KInF23GwnOBobo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=oD2hY4up9u6bgxrAaPsKtJdq5c5AD8TjZlKVJ+KSxjdKmPyxYj0eSG8oy+Lj19bLrM MxB4EnVn+IynennoZ56t2j72uqI+9ReAyCemiknEi6Ol2jMN30ly9zgL7Jn9T7tsvJ2e 9OB0bXDMln9jJNCfnyg8ckSnnR7u+o6E609Og= MIME-Version: 1.0 Received: by 10.68.33.97 with SMTP id q1mr2709025pbi.424.1304677939752; Fri, 06 May 2011 03:32:19 -0700 (PDT) Received: by 10.68.58.135 with HTTP; Fri, 6 May 2011 03:32:19 -0700 (PDT) In-Reply-To: <4DC0BDC5.8070402@gmail.com> References: <4DB95962.5090407@gmail.com> <192669.64705.qm@web111411.mail.gq1.yahoo.com> <01df01cc0953$0c23a560$246af020$@com> <4DC0BDC5.8070402@gmail.com> Date: Fri, 6 May 2011 18:32:19 +0800 Message-ID: From: GangChen To: buptnoc Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: behave@ietf.org, Dan Wing Subject: Re: [BEHAVE] =?gb2312?b?KioqU1BBTSoqKiA1LjU0OCAoNSkgSXMgbmF0NDYgd29y?= =?gb2312?b?dGggcmVzZWFyY2hpbmejvw==?= 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, 06 May 2011 10:32:20 -0000 Operators prefer to deploy IPv6-only in an brand-new network (e.g. Internet of things). Also, we could abserve that operators have already deployed IPv6-only network considering network transition. NAT46 could facilitate the interworking with legacy IPv4 Internet/network. In my mind, NAT46 can also serve for servers with both IPv4 and IPv6 addres= s. In some cases, public IPv4 pool embeded in NAT is running out due to numerous concurrent seesions. NAT would reject subsequent session requests. NAT46 could allow subsquent sessions keep working. 2011/5/4, buptnoc : > In my opinion, NAT46 is a network-side translation technology , need no > modification to host's protocol stack and only does translation once . > Other technology involved host-side translation or twice translation > such as BIH\PNAT is applied in different scenarios with NAT46. > NAT46 has a little difficulty to implement. But now I mainly want to > know whether it makes sense to research or deploy NAT46. > I think NAT46 depend on the emerging IPv6-only server, but does ISP or > ICP need IPv6-only server considering the shortage of IPv4? > > =D3=DA 2011-5-3 13:29, Dan Wing =D0=B4=B5=C0: >>> -----Original Message----- >>> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On >>> Behalf Of Behcet Sarikaya >>> Sent: Monday, May 02, 2011 8:18 AM >>> To: Iljitsch van Beijnum; buptnoc >>> Cc: softwires@ietf.org; behave@ietf.org >>> Subject: Re: [BEHAVE] ***SPAM*** 5.548 (5) Is nat46 worth researching= =A3=BF >>> >>> This is good point. >>> But maybe this should be discussed in Softwires list. >> NAT46 is in scope of BEHAVE, and is not in scope of SOFTWIRE. The >> BEHAVE charter is clear on that. >> >> But I have not yet understood how or where we would see an IPv4-only >> client needing to access an IPv6-only server (that is, a server >> with only an IPv6 address). >> >> -d > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From iljitsch@muada.com Sun May 8 07:51:14 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 109D7E070F for ; Sun, 8 May 2011 07:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.148 X-Spam-Level: X-Spam-Status: No, score=-102.148 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, SARE_SUB_ENC_UTF8=0.152, 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 c-8BYvTi20Hb for ; Sun, 8 May 2011 07:51:13 -0700 (PDT) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id 52EF5E0787 for ; Sun, 8 May 2011 07:51:13 -0700 (PDT) Received: from [IPv6:2001:470:1f0b:1289:223:12ff:fe56:36b2] ([IPv6:2001:470:1f0b:1289:223:12ff:fe56:36b2]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id p48EqLac067496 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 8 May 2011 16:52:22 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: Date: Sun, 8 May 2011 16:51:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DB95962.5090407@gmail.com> To: GangChen X-Mailer: Apple Mail (2.1084) Cc: "behave@ietf.org WG" Subject: Re: [BEHAVE] =?utf-8?q?Is_nat46_worth_researching=EF=BC=9F?= 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, 08 May 2011 14:51:14 -0000 On 6 mei 2011, at 9:02, GangChen wrote: >> Because of >> lack of IPv4 addresses, a relatively small pool of v4 addresses would = have >> to map to all possible v6 addresses, which means that the mappings = have to >> be highly dynamic. But addresses are cached in many places, including = often >> for a long time in applications. Having different applications react >> differently to NAT46 would be a big deployment problem. > Could you elaborate this deployment problem? > I can't fully understand your point. With NAT46, where an IPv4 client wants to connect to an IPv6 server = through a translation device, if an IPv4 system wants to talk to an IPv6 = system a NAT46 has to reserve an IPv4 address that is mapped to the = target IPv6 address. The number of IPv6 destinations is potentially = extremely large, while the pool of IPv4 addresses that can be mapped to = those IPv6 addresses can't be all that large because of lack of IPv4 = addresses. Problems occur if a mapping is removed and a new one created = for a given IPv4 address from this pool while the address is still = cached somewhere so an application at some point connects to the address = expecting to connect to the IPv6 host that was previously mapped to but = connects to the one that corresponds to the new mapping. It can be argued that in practice the number of IPv6 destinations that = the IPv4 systems will want to talk to is limited and the system can be = optimized to map based on source address of the client as well as = destination, but this will never be as simple as NAT64 where this = problem doesn't exist. It would be much better to spend all this effort upgrading to IPv6, or = if that isn't possible for some reason, to make applications work = through an HTTPS proxy and deploy HTTP/HTTPS proxies so IPv4 hosts can = reach IPv6 destinations. All TCP-based applications can be modified to = work through an HTTPS proxy. From cb.list6@gmail.com Sun May 8 09:35: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 45F94E0797 for ; Sun, 8 May 2011 09:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[AWL=0.425, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] 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 YIc2MDAVqAiu for ; Sun, 8 May 2011 09:35:49 -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 4B3B4E06A1 for ; Sun, 8 May 2011 09:35:48 -0700 (PDT) Received: by eye13 with SMTP id 13so1647255eye.31 for ; Sun, 08 May 2011 09:35:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1NxwvE/oqABgQHDFNI+TpKqUzsotQqN8vfoGlldBDHQ=; b=aKhueOkZ0vMC8K9RB9F6wn6cTdinY57kQfL+/eb2PSzToGk01qF+j+9gUTRQTrDbF4 7y5yJsSjtbNt1VlXAWzomnPatW28Vg6L3LsdtD7WOwJSDkwQBTQqUMVgKteY8jq2lPWP zLY305UkI2DgRinbVsm1JJ+t5QA9qVvIJqqJk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=cRd2YzoOiR7qVXjDb+p1DhOB2cCpYezcLDeleqvi3WyQPr78SGCa9WB2rjylIjLX0X AOiYU6a0TCNHx4UVgFHoKDa4zAdqb4OBqFsKdwvbhBOz2u+4jt6Dt/V/auOZke1P+Oua 9T0XPE9JMiRCQjZE+N0BY5H/a9xQNDXgF51eM= MIME-Version: 1.0 Received: by 10.14.127.76 with SMTP id c52mr2944460eei.57.1304872546467; Sun, 08 May 2011 09:35:46 -0700 (PDT) Received: by 10.14.37.143 with HTTP; Sun, 8 May 2011 09:35:45 -0700 (PDT) Received: by 10.14.37.143 with HTTP; Sun, 8 May 2011 09:35:45 -0700 (PDT) In-Reply-To: References: <4DB95962.5090407@gmail.com> Date: Sun, 8 May 2011 09:35:45 -0700 Message-ID: From: Cameron Byrne To: Iljitsch van Beijnum Content-Type: multipart/alternative; boundary=90e6ba5bb8f39c024704a2c65051 Cc: "behave@ietf.org WG" , GangChen Subject: Re: [BEHAVE] =?utf-8?q?Is_nat46_worth_researching=EF=BC=9F?= 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, 08 May 2011 16:35:51 -0000 --90e6ba5bb8f39c024704a2c65051 Content-Type: text/plain; charset=ISO-8859-1 On May 8, 2011 7:51 AM, "Iljitsch van Beijnum" wrote: > > On 6 mei 2011, at 9:02, GangChen wrote: > > >> Because of > >> lack of IPv4 addresses, a relatively small pool of v4 addresses would have > >> to map to all possible v6 addresses, which means that the mappings have to > >> be highly dynamic. But addresses are cached in many places, including often > >> for a long time in applications. Having different applications react > >> differently to NAT46 would be a big deployment problem. > > > Could you elaborate this deployment problem? > > I can't fully understand your point. > > With NAT46, where an IPv4 client wants to connect to an IPv6 server through a translation device, if an IPv4 system wants to talk to an IPv6 system a NAT46 has to reserve an IPv4 address that is mapped to the target IPv6 address. The number of IPv6 destinations is potentially extremely large, while the pool of IPv4 addresses that can be mapped to those IPv6 addresses can't be all that large because of lack of IPv4 addresses. Problems occur if a mapping is removed and a new one created for a given IPv4 address from this pool while the address is still cached somewhere so an application at some point connects to the address expecting to connect to the IPv6 host that was previously mapped to but connects to the one that corresponds to the new mapping. > > It can be argued that in practice the number of IPv6 destinations that the IPv4 systems will want to talk to is limited and the system can be optimized to map based on source address of the client as well as destination, but this will never be as simple as NAT64 where this problem doesn't exist. > > It would be much better to spend all this effort upgrading to IPv6, or if that isn't possible for some reason, to make applications work through an HTTPS proxy and deploy HTTP/HTTPS proxies so IPv4 hosts can reach IPv6 destinations. All TCP-based applications can be modified to work through an HTTPS proxy. > > But not Skype Cb _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave --90e6ba5bb8f39c024704a2c65051 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On May 8, 2011 7:51 AM, "Iljitsch van Beijnum" <iljitsch@muada.com> wrote:
>
> On 6 mei 2011, at 9:02, GangChen wrote:
>
> >> Because of
> >> lack of IPv4 addresses, a relatively small pool of v4 address= es would have
> >> to map to all possible v6 addresses, which means that the map= pings have to
> >> be highly dynamic. But addresses are cached in many places, i= ncluding often
> >> for a long time in applications. Having different application= s react
> >> differently to NAT46 would be a big deployment problem.
>
> > Could you elaborate this deployment problem?
> > I can't fully understand your point.
>
> With NAT46, where an IPv4 client wants to connect to an IPv6 server th= rough a translation device, if an IPv4 system wants to talk to an IPv6 syst= em a NAT46 has to reserve an IPv4 address that is mapped to the target IPv6= address. The number of IPv6 destinations is potentially extremely large, w= hile the pool of IPv4 addresses that can be mapped to those IPv6 addresses = can't be all that large because of lack of IPv4 addresses. Problems occ= ur if a mapping is removed and a new one created for a given IPv4 address f= rom this pool while the address is still cached somewhere so an application= at some point connects to the address expecting to connect to the IPv6 hos= t that was previously mapped to but connects to the one that corresponds to= the new mapping.
>
> It can be argued that in practice the number of IPv6 destinations that= the IPv4 systems will want to talk to is limited and the system can be opt= imized to map based on source address of the client as well as destination,= but this will never be as simple as NAT64 where this problem doesn't e= xist.
>
> It would be much better to spend all this effort upgrading to IPv6, or= if that isn't possible for some reason, to make applications work thro= ugh an HTTPS proxy and deploy HTTP/HTTPS proxies so IPv4 hosts can reach IP= v6 destinations. All TCP-based applications can be modified to work through= an HTTPS proxy.
>
>

But not Skype

Cb _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.i= etf.org/mailman/listinfo/behave

--90e6ba5bb8f39c024704a2c65051-- From iljitsch@muada.com Sun May 8 09:44: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 C4B2AE06BE for ; Sun, 8 May 2011 09:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.148 X-Spam-Level: X-Spam-Status: No, score=-102.148 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, SARE_SUB_ENC_UTF8=0.152, 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 FDJC4nVwRU8w for ; Sun, 8 May 2011 09:44:59 -0700 (PDT) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id DC875E06A1 for ; Sun, 8 May 2011 09:44:58 -0700 (PDT) Received: from [IPv6:2001:470:1f0b:1289:223:12ff:fe56:36b2] ([IPv6:2001:470:1f0b:1289:223:12ff:fe56:36b2]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id p48Gk9Rf067868 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 8 May 2011 18:46:10 +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: Sun, 8 May 2011 18:44:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DB95962.5090407@gmail.com> To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: "behave@ietf.org WG" Subject: Re: [BEHAVE] =?utf-8?q?Is_nat46_worth_researching=EF=BC=9F?= 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, 08 May 2011 16:44:59 -0000 On 8 mei 2011, at 18:35, Cameron Byrne wrote: way too much quoted stuff > But not Skype So? Skype uses a very large bag of tricks to get through NATs. It could = easily apply one or two of those tricks to get from IPv4 to IPv6. We = know that it sometimes lets un-NATed hosts relay between two that are = behind NAT. In the same way, it could have a dual stack host relay = between an IPv4 client and an IPv6 client. It could also work through = NAT64 but there are some caveats, notably the issue of connecting a = client behind NAT44(4) and one behind NAT64 and the fact that NAT64 = assumes the use of DNS names, which aren't always available to = consumers. (For instance, if I do a reverse lookup on my IPv4 address = and then a forward lookup on that name I get NXDOMAIN.) But we don't have to worry about Skype anyway because Skype is a closed = system that doesn't use IETF protocols. From Internet-Drafts@ietf.org Mon May 9 09:30:09 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89024E0851; Mon, 9 May 2011 09:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 4UuyMODS5SVn; Mon, 9 May 2011 09:30:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F32DE085A; Mon, 9 May 2011 09:30:03 -0700 (PDT) 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.53 Message-ID: <20110509163003.30973.76585.idtracker@ietfa.amsl.com> Date: Mon, 09 May 2011 09:30:03 -0700 Cc: behave@ietf.org Subject: [BEHAVE] I-D ACTION:draft-ietf-behave-ftp64-09.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, 09 May 2011 16:30:09 -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 : An FTP ALG for IPv6-to-IPv4 translation Author(s) : I. van Beijnum Filename : draft-ietf-behave-ftp64-09.txt Pages : 16 Date : 2011-05-02 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 as best it can. 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-09.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-ftp64-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-09092302.I-D@ietf.org> --NextPart-- From behcetsarikaya@yahoo.com Mon May 9 10:08: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 133ECE0703 for ; Mon, 9 May 2011 10:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.039 X-Spam-Level: X-Spam-Status: No, score=-2.039 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] 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 195GCf7UKkdT for ; Mon, 9 May 2011 10:08:45 -0700 (PDT) Received: from nm28-vm0.bullet.mail.sp2.yahoo.com (nm28-vm0.bullet.mail.sp2.yahoo.com [98.139.91.234]) by ietfa.amsl.com (Postfix) with SMTP id 0A54EE06C3 for ; Mon, 9 May 2011 10:08:33 -0700 (PDT) Received: from [98.139.91.61] by nm28.bullet.mail.sp2.yahoo.com with NNFMP; 09 May 2011 17:08:30 -0000 Received: from [98.139.91.60] by tm1.bullet.mail.sp2.yahoo.com with NNFMP; 09 May 2011 17:08:30 -0000 Received: from [127.0.0.1] by omp1060.mail.sp2.yahoo.com with NNFMP; 09 May 2011 17:08:30 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 35292.38771.bm@omp1060.mail.sp2.yahoo.com Received: (qmail 88884 invoked by uid 60001); 9 May 2011 17:08:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1304960909; bh=3JomOm2/ECtKbw5n9b3abi9qAyshsWvWm9RhMx/TwpQ=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=5NyPoB2pLwFUkmsMVl+5bRWDE1E97W9UDaCykZLxV7D4NAkJYYPzrjDa4UtuBu92v06WbJTmatQmWZGlxxxk5ZXC2PGzb8Y4IkMRy6w2pCb3bB71C96NSzpqIKGSL9UPQPTkIpV1XQ3ONpCKHpGXB5mlJOqXIQvYTlFNWCAdunE= 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:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=QnXLbyPRsdkdgN18tSPfJJGvzMPHxYbxUuBMN+gDWchU9ShjgKrBZIUuUYvIB+nby9Q/RJRBlMo7sKSmE4AEM4aggUWCI4V16qcZdn9uflHHV9Z5hqtFwfpcmJrLXUADAXSWfQ4sbWcq6jehIQE2wvrhGpfWzjd0irUhFZOWdSY=; Message-ID: <626885.40271.qm@web111405.mail.gq1.yahoo.com> X-YMail-OSG: 2qX.L7kVM1mJj.habMJVeTrxzvNqAQRiuxeF50HvCVXdYBY 7Lm1w50UD Received: from [206.16.17.212] by web111405.mail.gq1.yahoo.com via HTTP; Mon, 09 May 2011 10:08:29 PDT X-Mailer: YahooMailRC/559 YahooMailWebService/0.8.110.299900 References: <4DB95962.5090407@gmail.com> Date: Mon, 9 May 2011 10:08:29 -0700 (PDT) From: Behcet Sarikaya To: Iljitsch van Beijnum , Cameron Byrne In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "behave@ietf.orgWG" Subject: Re: [BEHAVE] =?utf-8?q?Is_nat46_worth_researching=EF=BC=9F?= X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 17:08:46 -0000 For Skype, BIH solution (NAT46 in the host and then NAT64 in the network) i= s the =0Abest I think.=0A=0A=0A=0A=0A> On 8 mei 2011, at 18:35, Cameron Byr= ne wrote:=0A> =0A> way too much quoted stuff=0A> =0A> > But not Skype=0A> = =0A> So? Skype uses a very large bag of tricks to get through NATs. It cou= ld easily =0A>apply one or two of those tricks to get from IPv4 to IPv6. W= e know that it =0A>sometimes lets un-NATed hosts relay between two that ar= e behind NAT. In the =0A>same way, it could have a dual stack host relay b= etween an IPv4 client and an =0A>IPv6 client. It could also work through NA= T64 but there are some caveats, =0A>notably the issue of connecting a clie= nt behind NAT44(4) and one behind NAT64 =0A>and the fact that NAT64 assume= s the use of DNS names, which aren't always =0A>available to consumers. (F= or instance, if I do a reverse lookup on my IPv4 =0A>address and then a fo= rward lookup on that name I get NXDOMAIN.)=0A> =0A> But we don't have to w= orry about Skype anyway because Skype is a closed system =0A>that doesn't = use IETF protocols.=0A> =0A> _____________________________________________= __=0A> Behave mailing list=0A> Behave@ietf.org=0A> https://www.ietf.org/ma= ilman/listinfo/behave=0A> From iljitsch@muada.com Mon May 9 10:16:01 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 13E39E0825 for ; Mon, 9 May 2011 10:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.497 X-Spam-Level: X-Spam-Status: No, score=-102.497 tagged_above=-999 required=5 tests=[AWL=0.102, 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 0vOJKH8g56X3 for ; Mon, 9 May 2011 10:16:00 -0700 (PDT) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id DD547E062A for ; Mon, 9 May 2011 10:15:32 -0700 (PDT) Received: from claw.it.uc3m.es ([163.117.139.50]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id p49HGf81074556 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 9 May 2011 19:16:41 +0200 (CEST) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Iljitsch van Beijnum In-Reply-To: <20110509163003.30973.76585.idtracker@ietfa.amsl.com> Date: Mon, 9 May 2011 19:14:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110509163003.30973.76585.idtracker@ietfa.amsl.com> To: "behave@ietf.org WG" X-Mailer: Apple Mail (2.1084) Subject: Re: [BEHAVE] I-D ACTION:draft-ietf-behave-ftp64-09.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, 09 May 2011 17:16:01 -0000 On 9 mei 2011, at 18:30, Internet-Drafts@ietf.org wrote: > A new Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Behavior Engineering for Hindrance = Avoidance Working Group of the IETF. > Title : An FTP ALG for IPv6-to-IPv4 translation > Author(s) : I. van Beijnum > Filename : draft-ietf-behave-ftp64-09.txt > Pages : 16 > Date : 2011-05-02 In case anyone's wondering: there are no changes to the text, just = pointers to the new RFCs. (And the draft was published a week ago, why = the delay?)= From cb.list6@gmail.com Mon May 9 10:16: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 CB1ABE06BE for ; Mon, 9 May 2011 10:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.75 X-Spam-Level: X-Spam-Status: No, score=-2.75 tagged_above=-999 required=5 tests=[AWL=0.397, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] 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 x6dKqiOW5VBc for ; Mon, 9 May 2011 10:16:19 -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 B1E18E06E9 for ; Mon, 9 May 2011 10:15:52 -0700 (PDT) Received: by eye13 with SMTP id 13so1971315eye.31 for ; Mon, 09 May 2011 10:15:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qRJH/R4ZTb8rWBMWDX5Y53xncbRNumEbC+duQgpTgOE=; b=qx0QdypIuRLaVOnYaMS2yCAksv3+7IeS7gjK+wDOAhqposdilyjlQrxALxa6qLaFUV CotU57tyvlTIyPuNpacy2xnedTaKj6c3Ow89pWliNCyv6UcCXnbMA2xrh0hxN3U8kd2s YYtmj55kcltWzJ7S6sYSyiz9OWuRPl14yMfP4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=HyO4fVa+UyI/W1zgn6wP64jNleRUfMVJVozYb3eLVQdxJEUCfCcjZf7pyRKSM7a+ji xTKs8jGtkySTQQzQd0Ln6p1lk7Tas92ScgHSyw1O24rap2Fp/MYTB/XCb/oHnbyzH8vU PKWdS37bH7qMtQzotnjBnkxx4ANs7RqQny0Us= MIME-Version: 1.0 Received: by 10.14.122.201 with SMTP id t49mr3111103eeh.25.1304961351865; Mon, 09 May 2011 10:15:51 -0700 (PDT) Received: by 10.14.37.143 with HTTP; Mon, 9 May 2011 10:15:51 -0700 (PDT) In-Reply-To: <626885.40271.qm@web111405.mail.gq1.yahoo.com> References: <4DB95962.5090407@gmail.com> <626885.40271.qm@web111405.mail.gq1.yahoo.com> Date: Mon, 9 May 2011 10:15:51 -0700 Message-ID: From: Cameron Byrne To: Behcet Sarikaya Content-Type: text/plain; charset=ISO-8859-1 Cc: "behave@ietf.orgWG" Subject: Re: [BEHAVE] =?utf-8?q?Is_nat46_worth_researching=EF=BC=9F?= 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, 09 May 2011 17:16:19 -0000 On Mon, May 9, 2011 at 10:08 AM, Behcet Sarikaya wrote: > For Skype, BIH solution (NAT46 in the host and then NAT64 in the network) is the > best I think. > Technically BIH does not work since it requires a DNS lookup for the BIH mapper. Skype and other non-DNS apps will continue to fail in an IPv6-only access network. This code does work and solves a real problem the IETF chooses not to address http://code.google.com/p/n900ipv6/wiki/Nat64D Cameron From behcetsarikaya@yahoo.com Mon May 9 12:12: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 E200CE06C7 for ; Mon, 9 May 2011 12:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] 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 y9LG7xxhlevF for ; Mon, 9 May 2011 12:12:47 -0700 (PDT) Received: from nm25-vm0.bullet.mail.sp2.yahoo.com (nm25-vm0.bullet.mail.sp2.yahoo.com [98.139.91.228]) by ietfa.amsl.com (Postfix) with SMTP id 84A7CE068B for ; Mon, 9 May 2011 12:12:47 -0700 (PDT) Received: from [98.139.91.66] by nm25.bullet.mail.sp2.yahoo.com with NNFMP; 09 May 2011 19:12:47 -0000 Received: from [98.139.91.56] by tm6.bullet.mail.sp2.yahoo.com with NNFMP; 09 May 2011 19:12:46 -0000 Received: from [127.0.0.1] by omp1056.mail.sp2.yahoo.com with NNFMP; 09 May 2011 19:12:46 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 951406.96527.bm@omp1056.mail.sp2.yahoo.com Received: (qmail 53628 invoked by uid 60001); 9 May 2011 19:12:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1304968365; bh=XuHAyHVgwOTJFpFivUd3p7lNCN/jKciMcpP5Tz0p8DQ=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=i1L15cnhe/VSqNeX69HKVp4HVxFJrvtdo+iSg8rQe0SyS69Mygn/0qhs/eJBc8/bUQ7VxlU8nNFCwKKcF9ETSfeMf9OpxCWdXkaoXQ6y6Iiq34p5yF5V1UW0L9E9vY7PXAPRKqSgHhxWW0lstGLhpvEHSuo6zdZJUQd0C1+Znkk= 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:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=m8dzxyaNF1oy7ThCPHaw5KHCVBW/rb/HVw8ac98rxbYbnvwymk6oikt9xWq36T+vhlFhDtYQC7UcZhk5ZqYuszIO3CXfl7SS1Af2iCZss9nDEJQbf56FTKrCxM71gO8rtVvj3zr7Nffm/EQB0XexPYYzz/Hg504fpjdHeAEG7jc=; Message-ID: <858570.52926.qm@web111403.mail.gq1.yahoo.com> X-YMail-OSG: WsgqGZAVM1nwMZ0QlEtzOcAWcRBtJ00CgOkIJdPLoA2ow46 vwBqqSzs.CJPrIfWIF_8M.UC_eac8nHCgXCDFKNzmyOoiDNVi11EXRXNwzGO i9MCms59UI0731rks3TAQJ7OwdVUKaVQGVJLkNi6GqToGFJURTIZn.lYsSpY PvtLAGHn67LpWHy0BK5CkI_9blmb2X0fmEX_Qx63Z4C9_sm2XKj3kEUnAyBD np2pU7Fz7JXDAQJCVphUqC2scXgHIlx1rANs_Owxl2ZcBvO37xsIBXQNrC8b UsHVCHCT0RvaIWWfYFf69pfUcN0QqTBwjWa.Yn4Ujc1SLktPjZ0GAeoqaLhw 4agGVoa0J4XM.XbYuW1ahPOgfc8wYiRUUwk9p35RnmFyVrbb5n7ymXa17FSC HsXaqEowov.cOVbIMm3ZkPxn_zrJHEradVbtmsZg_KS5lwNpGKNqVGQd0Cuc vXwyOsATb.SfMvUEZ3mH8B5NFUKqvU5PAip785oLDKxbj Received: from [206.16.17.212] by web111403.mail.gq1.yahoo.com via HTTP; Mon, 09 May 2011 12:12:45 PDT X-Mailer: YahooMailRC/559 YahooMailWebService/0.8.110.299900 References: <4DB95962.5090407@gmail.com> <626885.40271.qm@web111405.mail.gq1.yahoo.com> Date: Mon, 9 May 2011 12:12:45 -0700 (PDT) From: Behcet Sarikaya To: Cameron Byrne In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "behave@ietf.orgWG" Subject: Re: [BEHAVE] =?utf-8?q?Is_nat46_worth_researching=EF=BC=9F?= X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 19:12:48 -0000 =0A=0A=0A=0A> On Mon, May 9, 2011 at 10:08 AM, Behcet Sarikaya=0A> wrote:=0A> > For Skype, BIH solution (NAT46 in the host= and then NAT64 in the network) is =0A>the=0A> > best I think.=0A> >=0A> = =0A> Technically BIH does not work since it requires a DNS lookup for the= =0A> BIH mapper. Skype and other non-DNS apps will continue to fail in an= =0A> IPv6-only access network.=0A> =0A> This code does work and solves a r= eal problem the IETF chooses not to address=0A> =0A> http://code.google.= com/p/n900ipv6/wiki/Nat64D=0A=0AIETF works on drafts. Is there a draft on N= AT64D?=0A=0ARegards,=0A=0ABehcet=0A From cb.list6@gmail.com Mon May 9 12:22:57 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6A3DE07EA for ; Mon, 9 May 2011 12:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.775 X-Spam-Level: X-Spam-Status: No, score=-2.775 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] 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 Z2eEcoKLKSki for ; Mon, 9 May 2011 12:22:56 -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 129F4E0792 for ; Mon, 9 May 2011 12:22:55 -0700 (PDT) Received: by eye13 with SMTP id 13so2008041eye.31 for ; Mon, 09 May 2011 12:22:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+WpRW1ZfnqJuYkkYfubju6Zp12qURV4RHz2NI6zrwIg=; b=P3qzRB52BUfzJMqvO/sN9dK2uXc12eJB20OpP/B+jBGkibZsK0gRqEGh/YBK5mi2Ur 4Ng8fUBqXUVOzH4nrI4GEyMF923n1ryW4YM4Sh4kB0UepbUyapXZY7k1ZoxGrmz+xrZl 2yjvg862fBm2+2LocjFg6zDvTXFm1BtrJis4w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=FIfat04uYwyGMUpO2NIB2MEMBmEFwwA76zaxeN9JcVsONWxMdalrRFvI1fFv+3Lkeq 4KYiUDKdYLfHZrp9FOP1uJFH7XUyC3fJzD96zPGJZJMTlllby4KytII6qiWtN+3/9amr 6drCdrtku5uVc+VWBj4jgeFXltTPf6SJwZuKI= MIME-Version: 1.0 Received: by 10.14.21.133 with SMTP id r5mr3262934eer.249.1304968637387; Mon, 09 May 2011 12:17:17 -0700 (PDT) Received: by 10.14.37.143 with HTTP; Mon, 9 May 2011 12:17:17 -0700 (PDT) In-Reply-To: <858570.52926.qm@web111403.mail.gq1.yahoo.com> References: <4DB95962.5090407@gmail.com> <626885.40271.qm@web111405.mail.gq1.yahoo.com> <858570.52926.qm@web111403.mail.gq1.yahoo.com> Date: Mon, 9 May 2011 12:17:17 -0700 Message-ID: From: Cameron Byrne To: Behcet Sarikaya Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "behave@ietf.orgWG" Subject: Re: [BEHAVE] =?utf-8?q?Is_nat46_worth_researching=EF=BC=9F?= 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, 09 May 2011 19:22:57 -0000 On Mon, May 9, 2011 at 12:12 PM, Behcet Sarikaya wrote: > > > > >> On Mon, May 9, 2011 at 10:08 AM, Behcet Sarikaya >> =A0wrote: >> > For Skype, BIH solution (NAT46 in the host and then NAT64 in the =A0ne= twork) is >>the >> > best I think. >> > >> >> Technically BIH does not =A0work since it requires a DNS lookup for the >> BIH mapper. =A0Skype and other =A0non-DNS apps will continue to fail in = an >> IPv6-only access =A0network. >> >> This code does work and solves a real problem the IETF chooses =A0not to= address >> >> =A0 http://code.google.com/p/n900ipv6/wiki/Nat64D > > IETF works on drafts. Is there a draft on NAT64D? > No, NAT64D is not documented in the IETF. I am told there is no appetite for something that looks like NAT464 in the IETF, even though it solves a real problem. BIH is close, but it explicitly excludes the use in combination with NAT64 and requires DNS interactions .... so it will not work for applications like Skype or anything else that uses IPv4 referrals. Cameron > Regards, > > Behcet > > From behcetsarikaya@yahoo.com Mon May 9 13:30: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 467E7E074F for ; Mon, 9 May 2011 13:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.052 X-Spam-Level: X-Spam-Status: No, score=-2.052 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] 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 RPk+sAu7+nMb for ; Mon, 9 May 2011 13:30:06 -0700 (PDT) Received: from nm22-vm0.bullet.mail.sp2.yahoo.com (nm22-vm0.bullet.mail.sp2.yahoo.com [98.139.91.222]) by ietfa.amsl.com (Postfix) with SMTP id D6E59E06EC for ; Mon, 9 May 2011 13:30:06 -0700 (PDT) Received: from [98.139.91.67] by nm22.bullet.mail.sp2.yahoo.com with NNFMP; 09 May 2011 20:30:06 -0000 Received: from [98.139.91.20] by tm7.bullet.mail.sp2.yahoo.com with NNFMP; 09 May 2011 20:30:06 -0000 Received: from [127.0.0.1] by omp1020.mail.sp2.yahoo.com with NNFMP; 09 May 2011 20:30:06 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 51455.18666.bm@omp1020.mail.sp2.yahoo.com Received: (qmail 78542 invoked by uid 60001); 9 May 2011 20:30:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1304973001; bh=Z5ToCLGTfPvTvi47NRGClHN2zd+4gtKaEZmzD7Aw/mg=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=nkiu5OKxrw/eLgD4EvelvursALE0+jV3/pIv9exUh7Cu+lT6UnnCXqX/bfHiGK23s80ceQP5TNj3yqxZTjHr0B4IMtWz9uoLIzeCODo1n9BHX03HOnE/JHMs91zZUtZgXso8nCJRmeb5viHKp2KxsTZcb2TOA/LnL7+r5nUr0G0= 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:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=VnB0c5WnCxEzBMON0io+MAhIIrgJrq9naZ3H4WRRrT1fJ4R4EHn44N+Q6kOUOvehiul2V6Lj+cjbooL9zLyoLCD/m/cM8qhG+DwJvCcTxUme5v+c28/Zj8GrJm6g7213e3guEP0MwRIfFdGGqg5HZwiHCtmTyxQ5FThdOAwxiwQ=; Message-ID: <596387.68459.qm@web111408.mail.gq1.yahoo.com> X-YMail-OSG: 5JrA0Z0VM1lLHQ46JSZIuH4DPO.0u1gLxeb6evMD4z4x67X 5J9m9BuCfBhZmXXYqsxMRvlnNSIMJON29jnu90DVnfv2n78aVY2GgZWqld_b ji8AzXEwmXVfQA9pD0fjkPtZ3xCNOTgs6ZyB7sRPJh0u2pP.smgi5WzGDy.N Rf62QGpiWkwGd0NCEToTZ.HwVxtovkn49sKRfzagWCI4AMbabnAxX5_ALLzQ R7B35.UmwVcya.vIl9.SIp_ZC5bBB2Mw73VXAvc1OiNWCZuedsLD4HSXEvFo N1fw0S.dftM5jT88MtbvniG4fBoZFzKI1x5G8CFbOu6U86opnsiBR2urFiw2 fWwF6GlN3azIE0jnJP7Yb5VoRozX1vLzDpBu7j74F.b1r4TcDTueypewpY4W lkELClt0EmngGqwo8ihaCoM.ptJECpqVTVD9poCOdaGKOG46wwN7cbPmOLi0 7bgkbq_rp27Y45VwElgFQiri8h8tgnBpNaVAQ5hzgmQQJ Received: from [206.16.17.212] by web111408.mail.gq1.yahoo.com via HTTP; Mon, 09 May 2011 13:30:01 PDT X-Mailer: YahooMailRC/559 YahooMailWebService/0.8.110.299900 References: <4DB95962.5090407@gmail.com> <626885.40271.qm@web111405.mail.gq1.yahoo.com> <858570.52926.qm@web111403.mail.gq1.yahoo.com> Date: Mon, 9 May 2011 13:30:01 -0700 (PDT) From: Behcet Sarikaya To: Cameron Byrne In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "behave@ietf.orgWG" Subject: Re: [BEHAVE] =?utf-8?q?Is_nat46_worth_researching=EF=BC=9F?= X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 20:30:07 -0000 Cameron, I don't know BIH details but =0Acouldn't it be integrated with an= application like Skype on a smart phone =0Aapplication? Then there is no n= eed for a DNS lookup.=0A=0ARegards,=0A=0ABehcet=0A=0A> On Mon, May 9, 2011 = at 12:12 PM, Behcet Sarikaya=0A> wrote:=0A> >= =0A> >=0A> >=0A> >=0A> >> On Mon, May 9, 2011 at 10:08 AM, Behcet Sarikaya= =0A> >> wrote:=0A> >> > For Skype, BIH solutio= n (NAT46 in the host and then NAT64 in the =0A> network) is=0A> >>the=0A> = >> > best I think.=0A> >> >=0A> >>=0A> >> Technically BIH does not work = since it requires a DNS lookup for the=0A> >> BIH mapper. Skype and other = non-DNS apps will continue to fail in an=0A> >> IPv6-only access networ= k.=0A> >>=0A> >> This code does work and solves a real problem the IETF ch= ooses not to =0A>address=0A> >>=0A> >> http://code.google.com/p/n900ipv= 6/wiki/Nat64D=0A> >=0A> > IETF works on drafts. Is there a draft on NAT64D= ?=0A> >=0A> =0A> No, NAT64D is not documented in the IETF.=0A> =0A> I am t= old there is no appetite for something that looks like NAT464 in=0A> the I= ETF, even though it solves a real problem.=0A> =0A> BIH is close, but it e= xplicitly excludes the use in combination with=0A> NAT64 and requires DNS = interactions .... so it will not work for=0A> applications like Skype or a= nything else that uses IPv4 referrals.=0A> =0A> Cameron=0A> =0A> > Regards= ,=0A> >=0A> > Behcet=0A> >=0A> >=0A> _____________________________________= __________=0A> Behave mailing list=0A> Behave@ietf.org=0A> https://www.iet= f.org/mailman/listinfo/behave=0A> From iljitsch@muada.com Mon May 9 13:30: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 67A91E0912 for ; Mon, 9 May 2011 13:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.148 X-Spam-Level: X-Spam-Status: No, score=-102.148 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152, 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 q7pVfFqk5sUw for ; Mon, 9 May 2011 13:30:45 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id F12ECE073C for ; Mon, 9 May 2011 13:30:44 -0700 (PDT) Received: from [192.168.0.140] (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 p49KVieu075887 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 9 May 2011 22:31:50 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: Date: Mon, 9 May 2011 22:30:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DB95962.5090407@gmail.com> <626885.40271.qm@web111405.mail.gq1.yahoo.com> <858570.52926.qm@web111403.mail.gq1.yahoo.com> To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: Behcet Sarikaya , "behave@ietf.orgWG" Subject: [BEHAVE] =?utf-8?q?NAT464_of_sorts=2C_was=3A_Re=3A__Is_nat46_wort?= =?utf-8?q?h_researching=EF=BC=9F?= 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, 09 May 2011 20:30:51 -0000 On 9 mei 2011, at 21:17, Cameron Byrne wrote: >>> Technically BIH does not work since it requires a DNS lookup for = the >>> BIH mapper. Skype and other non-DNS apps will continue to fail in = an >>> IPv6-only access network. >>> This code does work and solves a real problem the IETF chooses not = to address >>=20 > NAT64D is not documented in the IETF. > I am told there is no appetite for something that looks like NAT464 in > the IETF, even though it solves a real problem. I'm guessing the softwires people say that because in their opinion = having an extra IPv4 header in there makes everything much more = appealing. However, I've always been of the opinion that it's suboptimal to have = two slightly different translation boxes that take IPv6 packets as input = and produce IPv4 packets as output. I guess dslite is a good solution if = you put it in home gateways to serve unmodified IPv4 hosts, but I don't = see how it makes sense as a host-based solution. So how does NAT64D work?= From dwing@cisco.com Mon May 9 15:27:33 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05EB3E076B for ; Mon, 9 May 2011 15:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.135 X-Spam-Level: X-Spam-Status: No, score=-110.135 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, SARE_SUB_ENC_UTF8=0.152, 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 8WTxzqGlENh8 for ; Mon, 9 May 2011 15:27:32 -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 11C6FE06F2 for ; Mon, 9 May 2011 15:27:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1882; q=dns/txt; s=iport; t=1304980052; x=1306189652; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=TFTPKwY5/cfuoXrjrXTaCvjp7F9ZEPy1zeN4Id2ASKI=; b=lwDnP/t/FCWvrwNV8bV/X8ziy/3dQevL2ei4hRkDT50NZvmRPknJ59C2 HuEKowjVSItBIEb/NprTy5qyCk3Te4B22PlSDcnLs777NbYasZy+0FfDp K6k5CZ45H0GlMVEF4N2HQApzdk49/njH8rnoEi4/bUVib9BIH7UKwTaNk U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvcAANdpyE2rRDoH/2dsb2JhbACEUpMAD4FVjEt3iHGfFI0CkSyBKoNggQIEhkCRZIY+ X-IronPort-AV: E=Sophos;i="4.64,342,1301875200"; d="scan'208";a="444541792" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 09 May 2011 22:27:31 +0000 Received: from dwingWS ([10.32.240.195]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p49MRVfl021332; Mon, 9 May 2011 22:27:31 GMT From: "Dan Wing" To: "'Cameron Byrne'" , "'Behcet Sarikaya'" References: <4DB95962.5090407@gmail.com> <626885.40271.qm@web111405.mail.gq1.yahoo.com> <858570.52926.qm@web111403.mail.gq1.yahoo.com> In-Reply-To: Date: Mon, 9 May 2011 15:27:31 -0700 Message-ID: <069b01cc0e98$49507810$dbf16830$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcwOfpeoVJgUVhW1TGGEqTCXpH70OgAGVodg Content-Language: en-us Cc: behave@ietf.org Subject: Re: [BEHAVE] =?utf-8?q?Is_nat46_worth_researching=EF=BC=9F?= 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, 09 May 2011 22:27:33 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Cameron Byrne > Sent: Monday, May 09, 2011 12:17 PM > To: Behcet Sarikaya > Cc: behave@ietf.orgWG > Subject: Re: [BEHAVE] Is nat46 worth researching=EF=BC=9F >=20 > On Mon, May 9, 2011 at 12:12 PM, Behcet Sarikaya > wrote: > > > > > > > > > >> On Mon, May 9, 2011 at 10:08 AM, Behcet Sarikaya > >> wrote: > >> > For Skype, BIH solution (NAT46 in the host and then NAT64 in the > network) is > >>the > >> > best I think. > >> > > >> > >> Technically BIH does not work since it requires a DNS lookup for > the > >> BIH mapper. Skype and other non-DNS apps will continue to fail in > an > >> IPv6-only access network. > >> > >> This code does work and solves a real problem the IETF chooses not > to address > >> > >> http://code.google.com/p/n900ipv6/wiki/Nat64D > > > > IETF works on drafts. Is there a draft on NAT64D? > > >=20 > No, NAT64D is not documented in the IETF. >=20 > I am told there is no appetite for something that looks like NAT464 in > the IETF, even though it solves a real problem. The reason there is no appetite in the IETF is it removes the=20 incentive for the application to support IPv6. Which means the=20 transition technology (NAT464) persists in networks forever, becoming a permanent cost to network operation. -d > BIH is close, but it explicitly excludes the use in combination with > NAT64 and requires DNS interactions .... so it will not work for > applications like Skype or anything else that uses IPv4 referrals. >=20 > Cameron >=20 > > Regards, > > > > Behcet > > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From dwing@cisco.com Mon May 9 15:33:13 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC21E076B for ; Mon, 9 May 2011 15:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.555 X-Spam-Level: X-Spam-Status: No, score=-108.555 tagged_above=-999 required=5 tests=[AWL=-1.569, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, RCVD_IN_DNSWL_HI=-8, SARE_SUB_ENC_ISO2022JP=0.413, 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 oavXVo6fZnVt for ; Mon, 9 May 2011 15:33:12 -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 52D29E082B for ; Mon, 9 May 2011 15:33:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2676; q=dns/txt; s=iport; t=1304980392; x=1306189992; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=78X9BR1hFfWhH8efmkliyRfsy99iRv+o4Zea82yP0SI=; b=i3Kwt5BIQqJIRfGU0GtsL6vBid/dhYL+opxYWKqr49gtGj6nzH7Z1hEb A9h/7PHKnGT9CaISoSaZNUHV5BTz582rFrtJIahIbcd1HihuYFvJrTMTG I82zPFvXfwH823nD7gKaCrX+s9kdyac9RUCq8qEQzEALH5zt4MPUc6GgR k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvcAAIVqyE2rRDoH/2dsb2JhbACEUpMAD4FVjEt3iHGfE4x9AZEwgSeDYIEFBIZAkWSGPg X-IronPort-AV: E=Sophos;i="4.64,342,1301875200"; d="scan'208";a="353533219" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-2.cisco.com with ESMTP; 09 May 2011 22:33:12 +0000 Received: from dwingWS ([10.32.240.195]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p49MXBFd025719; Mon, 9 May 2011 22:33:11 GMT From: "Dan Wing" To: "'Behcet Sarikaya'" , "'Cameron Byrne'" References: <4DB95962.5090407@gmail.com> <626885.40271.qm@web111405.mail.gq1.yahoo.com> <858570.52926.qm@web111403.mail.gq1.yahoo.com> <596387.68459.qm@web111408.mail.gq1.yahoo.com> In-Reply-To: <596387.68459.qm@web111408.mail.gq1.yahoo.com> Date: Mon, 9 May 2011 15:33:11 -0700 Message-ID: <069c01cc0e99$143d7960$3cb86c20$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcwOiC2VdspDcYD1SQCTl+EWHFACVwAEBvvA Content-Language: en-us Cc: behave@ietf.org Subject: Re: [BEHAVE] =?iso-2022-jp?b?SXMgbmF0NDYgd29ydGggcmVzZWFyY2hpbmc=?= =?iso-2022-jp?b?GyRCISkbKEI=?= 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, 09 May 2011 22:33:13 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Behcet Sarikaya > Sent: Monday, May 09, 2011 1:30 PM > To: Cameron Byrne > Cc: behave@ietf.orgWG > Subject: Re: [BEHAVE] Is nat46 worth researching$B!)(B > > Cameron, I don't know BIH details but > couldn't it be integrated with an application like Skype on a smart > phone > application? Then there is no need for a DNS lookup. Here is the relevant text from BIH, http://tools.ietf.org/html/draft-ietf-behave-v4v6-bih-04 ... Protocol translation SHOULD NOT be performend for IPv4 packets sent to IPv4 address range used by local synthesis and for which mapping table entry does not exist. The implementation SHOULD attempt to route such packet via IPv4 interfaces instead. ... If there is a real A record available, the ENR SHOULD NOT synthesize IPv4 addresses. By default an ENR implementation MUST NOT synthesize IPv4 addresses when real A records exist. ... -d > Regards, > > Behcet > > > On Mon, May 9, 2011 at 12:12 PM, Behcet Sarikaya > > wrote: > > > > > > > > > > > > > > >> On Mon, May 9, 2011 at 10:08 AM, Behcet Sarikaya > > >> wrote: > > >> > For Skype, BIH solution (NAT46 in the host and then NAT64 in > the > > network) is > > >>the > > >> > best I think. > > >> > > > >> > > >> Technically BIH does not work since it requires a DNS lookup for > the > > >> BIH mapper. Skype and other non-DNS apps will continue to fail > in an > > >> IPv6-only access network. > > >> > > >> This code does work and solves a real problem the IETF chooses > not to > >address > > >> > > >> http://code.google.com/p/n900ipv6/wiki/Nat64D > > > > > > IETF works on drafts. Is there a draft on NAT64D? > > > > > > > No, NAT64D is not documented in the IETF. > > > > I am told there is no appetite for something that looks like NAT464 > in > > the IETF, even though it solves a real problem. > > > > BIH is close, but it explicitly excludes the use in combination with > > NAT64 and requires DNS interactions .... so it will not work for > > applications like Skype or anything else that uses IPv4 referrals. > > > > Cameron > > > > > Regards, > > > > > > Behcet > > > > > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From marka@isc.org Mon May 9 16:37: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 A791EE07A7 for ; Mon, 9 May 2011 16:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.876 X-Spam-Level: X-Spam-Status: No, score=-0.876 tagged_above=-999 required=5 tests=[AWL=-1.123, BAYES_00=-2.599, MANGLED_HOME=2.3, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8x2=0.246] 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 bWmMzY2JfTL1 for ; Mon, 9 May 2011 16:37:39 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 83BFBE07BD for ; Mon, 9 May 2011 16:37:39 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id BB7BFC94EC; Mon, 9 May 2011 23:37:27 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 52E55216C1E; Mon, 9 May 2011 23:37:27 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id D10EDE9AC0B; Tue, 10 May 2011 09:37:47 +1000 (EST) To: Iljitsch van Beijnum From: Mark Andrews References: <4DB95962.5090407@gmail.com> <626885.40271.qm@web111405.mail.gq1.yahoo.com> <858570.52926.qm@web111403.mail.gq1.yahoo.com> In-reply-to: Your message of "Mon, 09 May 2011 22:30:24 +0200." Date: Tue, 10 May 2011 09:37:47 +1000 Message-Id: <20110509233747.D10EDE9AC0B@drugs.dv.isc.org> Cc: Cameron Byrne , "behave@ietf.orgWG" , Behcet Sarikaya Subject: Re: [BEHAVE] =?utf-8?q?NAT464_of_sorts=2C_was=3A_Re=3A__Is_nat46_wort?= =?utf-8?q?h_researching=EF=BC=9F?= 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, 09 May 2011 23:37:40 -0000 In message , Iljitsch van Beijn um writes: > On 9 mei 2011, at 21:17, Cameron Byrne wrote: > > >>> Technically BIH does not work since it requires a DNS lookup for the > >>> BIH mapper. Skype and other non-DNS apps will continue to fail in an > >>> IPv6-only access network. > > >>> This code does work and solves a real problem the IETF chooses not to ad > dress > >> > > > NAT64D is not documented in the IETF. > > > I am told there is no appetite for something that looks like NAT464 in > > the IETF, even though it solves a real problem. > > I'm guessing the softwires people say that because in their opinion having an > extra IPv4 header in there makes everything much more appealing. > > However, I've always been of the opinion that it's suboptimal to have two sli > ghtly different translation boxes that take IPv6 packets as input and produce > IPv4 packets as output. I guess dslite is a good solution if you put it in h > ome gateways to serve unmodified IPv4 hosts, but I don't see how it makes sen > se as a host-based solution. It avoids any artifacts from doing double translation. > So how does NAT64D work? > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From buptnoc@gmail.com Mon May 9 22:11: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 5109BE0740 for ; Mon, 9 May 2011 22:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.536 X-Spam-Level: *** X-Spam-Status: No, score=3.536 tagged_above=-999 required=5 tests=[AWL=-2.502, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_GB2312=1.345] 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 0YloVw45mAhA for ; Mon, 9 May 2011 22:11:47 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id A1FB2E06BD for ; Mon, 9 May 2011 22:11:47 -0700 (PDT) Received: by pzk5 with SMTP id 5so3598124pzk.31 for ; Mon, 09 May 2011 22:11:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=rLsJy+Ufr+ok5P7VU5xbDRbleeyyOV9Gj1vM24llbW0=; b=rd9V9EHWiewnRq9hk5etswcApZwP8m+fnrkp6VDSZNNwgDeUpiczSPw6BAYFt/8osV kH4DD+XgJr2xKtoRGoiTGmekTpEXzLTRB3od8XtBfRxZBeNIM2j/ECtTBlo2sIMbturx 5plYg6Pj4aNwRxHrYCks1oCIlwtPKhgP47P0s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=U2/+x5QGVBFpF4hy3217Kz3k+3IQ2OrjlDJ2/s8vFW06iiuugbQ2dr80s4fDNY+kHq PkZl/PbhsutoPT2BVhyA0rLCPFIG1mq0++F+d/q5AeDIMglhbxmL5OtVr+aLJiWLBC7U ktHoPKgrrQ/qWmBjGKyEv7vHnnvg3utasxRUA= Received: by 10.142.61.33 with SMTP id j33mr4145403wfa.368.1305004307055; Mon, 09 May 2011 22:11:47 -0700 (PDT) Received: from [210.25.132.207] ([210.25.132.207]) by mx.google.com with ESMTPS id 25sm9019025wfb.22.2011.05.09.22.11.43 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 May 2011 22:11:46 -0700 (PDT) Message-ID: <4DC8C910.9040503@gmail.com> Date: Tue, 10 May 2011 13:11:44 +0800 From: buptnoc User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: GangChen References: <4DB95962.5090407@gmail.com> <192669.64705.qm@web111411.mail.gq1.yahoo.com> <01df01cc0953$0c23a560$246af020$@com> <4DC0BDC5.8070402@gmail.com> In-Reply-To: Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: 8bit Cc: behave@ietf.org Subject: Re: [BEHAVE] =?gb2312?b?KioqU1BBTSoqKiA1LjU0OCAoNSkgSXMgbmF0NDYgd29y?= =?gb2312?b?dGggcmVzZWFyY2hpbmejvw==?= 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, 10 May 2011 05:11:48 -0000 Great! Since Internet of things or Home network or other brand-new networks will cosume lots of address, IPv6 is the best choice. At the same time, most users need access those new network from IPv4-only Internet. So, NAT46 is needed.

Thank you all !

ÓÚ 2011-5-6 18:32, GangChen дµÀ: 
Operators prefer to deploy IPv6-only in an brand-new network (e.g.
Internet of things).
Also, we could abserve that operators have already deployed IPv6-only
network considering network transition.
NAT46 could facilitate the interworking with legacy IPv4 Internet/network.
In my mind, NAT46 can also serve for servers with both IPv4 and IPv6 address.
In some cases, public IPv4 pool embeded in NAT is running out due to
numerous concurrent seesions.
NAT would reject subsequent session requests. NAT46 could allow
subsquent sessions keep working.

2011/5/4, buptnoc <buptnoc@gmail.com>:

In my opinion, NAT46 is a network-side translation technology , need no
modification to host's protocol stack and only does translation once .
Other technology involved host-side translation or twice translation
such as BIH\PNAT is applied in different scenarios with NAT46.
NAT46 has a little difficulty to implement. But now I mainly want to
know whether it makes sense to research or deploy NAT46.
I think NAT46 depend on the emerging IPv6-only server, but does ISP or
ICP need IPv6-only server considering the shortage of IPv4?

ÓÚ 2011-5-3 13:29, Dan Wing дµÀ:

-----Original Message-----
From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On
Behalf Of Behcet Sarikaya
Sent: Monday, May 02, 2011 8:18 AM
To: Iljitsch van Beijnum; buptnoc
Cc: softwires@ietf.org; behave@ietf.org
Subject: Re: [BEHAVE] ***SPAM*** 5.548 (5) Is nat46 worth researching£¿

This is good point.
But maybe this should be discussed in Softwires list.

NAT46 is in scope of BEHAVE, and is not in scope of SOFTWIRE.  The
BEHAVE charter is clear on that.

But I have not yet understood how or where we would see an IPv4-only
client needing to access an IPv6-only server (that is, a server
with only an IPv6 address).

-d

_______________________________________________
Behave mailing list
Behave@ietf.org
https://www.ietf.org/mailman/listinfo/behave



    

  


From dwing@cisco.com  Mon May  9 22:22:43 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 180C1E06F8 for ; Mon,  9 May 2011 22:22:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.484
X-Spam-Level: 
X-Spam-Status: No, score=-108.484 tagged_above=-999 required=5 tests=[AWL=-1.498, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, RCVD_IN_DNSWL_HI=-8, SARE_SUB_ENC_ISO2022JP=0.413, 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 JBqxQd6PdStC for ; Mon,  9 May 2011 22:22:42 -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 0A8EBE0665 for ; Mon,  9 May 2011 22:22:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=3197; q=dns/txt; s=iport; t=1305004962; x=1306214562; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=NssjAFR2vQL0rIzCd2lhXmtps9Cdtp9TaBZMFqT4tgs=; b=A/a5qkT68a+jlFZ5mMLQE6Fhs6mZyWWmbCpzcEhW7lXQDk47Q7wt23ps uWb8aTtEERub6WrOt0SSlW9Uh4kHb4ZT2twtQn6eIMNAPjrZCJ9NOvLek hgaDNTTHBcYAFF58Wrd2XcZ49OeYVyy9hYkpBfr8zdd4/Q18vufWoazfS M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhoBABvLyE2rRDoG/2dsb2JhbACEUpMAgWSMTXemWIx9AZFCgSeEZwSGQZFshj4
X-IronPort-AV: E=Sophos;i="4.64,344,1301875200"; d="scan'208";a="444700160"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-1.cisco.com with ESMTP; 10 May 2011 05:20:21 +0000
Received: from dwingWS ([10.32.240.195]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4A5KK7P023899; Tue, 10 May 2011 05:20:20 GMT
From: "Dan Wing" 
To: "'buptnoc'" , "'GangChen'" 
References: <4DB95962.5090407@gmail.com>		<192669.64705.qm@web111411.mail.gq1.yahoo.com>	<01df01cc0953$0c23a560$246af020$@com>	<4DC0BDC5.8070402@gmail.com>	 <4DC8C910.9040503@gmail.com>
In-Reply-To: <4DC8C910.9040503@gmail.com>
Date: Mon, 9 May 2011 22:20:21 -0700
Message-ID: <07d701cc0ed1$f55e6660$e01b3320$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcwO0XiHdiR2agprR3i4PX/W/2H2JgAAEzlw
Content-Language: en-us
Cc: behave@ietf.org
Subject: Re: [BEHAVE] =?iso-2022-jp?b?KioqU1BBTSoqKiA1LjU0OCAoNSkgSXMgbmF0NDYg?= =?iso-2022-jp?b?d29ydGggcmVzZWFyY2hpbmcbJEIhKRsoQg==?=
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, 10 May 2011 05:22:43 -0000

> -----Original Message-----
> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On
> Behalf Of buptnoc
> Sent: Monday, May 09, 2011 10:12 PM
> To: GangChen
> Cc: behave@ietf.org
> Subject: Re: [BEHAVE] ***SPAM*** 5.548 (5) Is nat46 worth researching$B!)(B
>
> Great! Since Internet of things or Home network or other brand-new
> networks will cosume lots of address, IPv6 is the best choice. At the
> same time, most users need access those new network from IPv4-only
> Internet. So, NAT46 is needed.

The problem is deciding where that NAT46 is needed.  Is it
needed on the IPv4 side (where the IPv4 hosts are) or on the
IPv6 side (where the IPv6 hosts are).

The answer makes a substantial difference in architecture.

And one of them is already solved in the BEHAVE framework and
BEHAVE's published RFCs.

-d


> Thank you all !
>
> $BP2(B 2011-5-6 18:32, GangChen $B
> 	Operators prefer to deploy IPv6-only in an brand-new network
> (e.g.
> 	Internet of things).
> 	Also, we could abserve that operators have already deployed IPv6-
> only
> 	network considering network transition.
> 	NAT46 could facilitate the interworking with legacy IPv4
> Internet/network.
> 	In my mind, NAT46 can also serve for servers with both IPv4 and
> IPv6 address.
> 	In some cases, public IPv4 pool embeded in NAT is running out due
> to
> 	numerous concurrent seesions.
> 	NAT would reject subsequent session requests. NAT46 could allow
> 	subsquent sessions keep working.
>
> 	2011/5/4, buptnoc  
> :
>
> 		In my opinion, NAT46 is a network-side translation
> technology , need no
> 		modification to host's protocol stack and only does
> translation once .
> 		Other technology involved host-side translation or twice
> translation
> 		such as BIH\PNAT is applied in different scenarios with
> NAT46.
> 		NAT46 has a little difficulty to implement. But now I
> mainly want to
> 		know whether it makes sense to research or deploy NAT46.
> 		I think NAT46 depend on the emerging IPv6-only server, but
> does ISP or
> 		ICP need IPv6-only server considering the shortage of IPv4?
>
> 		$BP2(B 2011-5-3 13:29, Dan Wing $B
> 				-----Original Message-----
> 				From: behave-bounces@ietf.org
[mailto:behave-
> bounces@ietf.org] On
> 				Behalf Of Behcet Sarikaya
> 				Sent: Monday, May 02, 2011 8:18 AM
> 				To: Iljitsch van Beijnum; buptnoc
> 				Cc: softwires@ietf.org; behave@ietf.org
> 				Subject: Re: [BEHAVE] ***SPAM*** 5.548 (5)
Is
> nat46 worth researching$B!)(B
>
> 				This is good point.
> 				But maybe this should be discussed in
Softwires
> list.
>
> 			NAT46 is in scope of BEHAVE, and is not in scope of
> SOFTWIRE.  The
> 			BEHAVE charter is clear on that.
>
> 			But I have not yet understood how or where we would
> see an IPv4-only
> 			client needing to access an IPv6-only server (that
> is, a server
> 			with only an IPv6 address).
>
> 			-d
>
> 		_______________________________________________
> 		Behave mailing list
> 		Behave@ietf.org
> 		https://www.ietf.org/mailman/listinfo/behave
>
>
>



From behcetsarikaya@yahoo.com  Tue May 10 08:45:54 2011
Return-Path: 
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BBCBE078A for ; Tue, 10 May 2011 08:45:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.057
X-Spam-Level: 
X-Spam-Status: No, score=-2.057 tagged_above=-999 required=5 tests=[AWL=0.090,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152]
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 rjtKcvzo3RkD for ; Tue, 10 May 2011 08:45:53 -0700 (PDT)
Received: from nm30.bullet.mail.sp2.yahoo.com (nm30.bullet.mail.sp2.yahoo.com [98.139.91.100]) by ietfa.amsl.com (Postfix) with SMTP id D6B54E067C for ; Tue, 10 May 2011 08:45:53 -0700 (PDT)
Received: from [98.139.91.67] by nm30.bullet.mail.sp2.yahoo.com with NNFMP; 10 May 2011 15:45:50 -0000
Received: from [98.139.91.20] by tm7.bullet.mail.sp2.yahoo.com with NNFMP; 10 May 2011 15:45:50 -0000
Received: from [127.0.0.1] by omp1020.mail.sp2.yahoo.com with NNFMP; 10 May 2011 15:45:50 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 617252.49118.bm@omp1020.mail.sp2.yahoo.com
Received: (qmail 56156 invoked by uid 60001); 10 May 2011 15:45:50 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1305042350; bh=pj638FGgVvDxIfemSNd4ATjQbodfCDyK45ySgbCPccs=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Tl5So58Uxd4IU/Qfq1KNdgluQVpW+YyGnwR2cNUesOfhC5Uhx2J86Q2zzwWM8aCsrINNvqQPZd/BgkvN9SsBkT/HABo374Efm4GLNfu/2ld6w3zijCX4sGwTVf9TfKjhYz76H6Lkt5+V7UHUm4/tZ3d6ZV7l9hdRMelKYSyhPW0=
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:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=FH8BLR0R2OWCG6bbAH5/Fj9XP4OFMxkUvU2aDI6IY4ukoiDcc0PvfCP1mT8tXRhJT1JiCje2BOcQRD/9b2MP5CQuJrF8cRBwn4eFYGlbAKzwbQLIkouZoRYWToImj9yXJdWkXgjSi1Vg0PM5d4j6Olwh/6HbOZ9gkais6Y2Kq/M=;
Message-ID: <128586.54187.qm@web111407.mail.gq1.yahoo.com>
X-YMail-OSG: HTtZG2YVM1mJbKcBK4YM3Fx88xQfeBZbT.HvH11w0rD_ovD VJONWC80fJonCNBQ5xH9aWDf_dcmPwGTrBRM1HvhBk2d5D9SLJwcxnBAep3X Y6hHZFzH4AS1Du0Eew1efP4Bo4FWxmBCkCi0hbseNJEI4EAmGy1Sl.DqUL8P Z7Vr3KUiAQQGNyCBScfK8gkek4BRVDF__B3CepRSbFFZv3Is3islml4OQu7G Z2MbJp5JAORq6uWpVLOGD.xnTIRSsHxgU1MVY4mbPW0QRN48nLrwyj_NcOIc XmrifDA5aEA_tql8mw035XlscU0oD8armjGMoXw7zSFIhHMCQxdFmGW4v_yq 9oW5KXXsUcVCLhxKOrmI8qZOXMP61zs9uZ6G2fENOMfHxsH1_GYp1fMjXLrS GFsPsM_U4c5Yhz_7yeip6CLIj5JicVpg0z1f2HFfdKA--
Received: from [206.16.17.212] by web111407.mail.gq1.yahoo.com via HTTP; Tue, 10 May 2011 08:45:49 PDT
X-Mailer: YahooMailRC/559 YahooMailWebService/0.8.110.299900
References: <4DB95962.5090407@gmail.com>  <192669.64705.qm@web111411.mail.gq1.yahoo.com> <01df01cc0953$0c23a560$246af020$@com> <4DC0BDC5.8070402@gmail.com>  <4DC8C910.9040503@gmail.com>
Date: Tue, 10 May 2011 08:45:49 -0700 (PDT)
From: Behcet Sarikaya 
To: buptnoc , GangChen 
In-Reply-To: <4DC8C910.9040503@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: behave@ietf.org
Subject: Re: [BEHAVE] =?utf-8?q?***SPAM***_5=2E548_=285=29_Is_nat46_worth_rese?= =?utf-8?q?arching=EF=BC=9F?=
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Behcet Sarikaya 
List-Id: mailing list of BEHAVE IETF WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 May 2011 15:45:54 -0000

Remember one problem could be solved based on today's news: =0A=0ASkype cou=
ld become IPv6 soon.=0A=0AAlso there is 4rd which solves the problem of v4 =
host accessing v4 Internet from =0Av6 network and 4rd is stateless.=0A=0AGi=
ven all of the above I think we should get back to your original concern.=
=0A=0A>Great! Since Internet of things or Home     network or other brand-n=
ew networks =0A=0A>will cosume lots of address,     IPv6 is the best choice=
. At the same time, most =0A>=0A>users need access     those new network fr=
om IPv4-only Internet. So, NAT46 is =0A>needed. =0A>=0A>=0A>Thank you all !=
 =0A>=0A>=E4=BA=8E 2011-5-6 18:32, GangChen =E5=86=99=E9=81=93: =0A>Operato=
rs prefer to deploy IPv6-only in an brand-new network (e.g. Internet of =0A=
>things). Also, we could abserve that operators have already deployed IPv6-=
only =0A>network considering network transition. NAT46 could facilitate the=
 interworking =0A=0A>with legacy IPv4 Internet/network. In my mind, NAT46 c=
an also serve for servers =0A=0A>with both IPv4 and IPv6 address. In some c=
ases, public IPv4 pool embeded in NAT =0A=0A>is running out due to numerous=
 concurrent seesions. NAT would reject subsequent =0A=0A>session requests. =
NAT46 could allow subsquent sessions keep working.  2011/5/4, =0A=0A>buptno=
c : =0A>=0A>>In my opinion, NAT46 is a network-side tran=
slation technology , need no =0A>>modification to host's protocol stack and=
 only does translation once . Other =0A>>technology involved host-side tran=
slation or twice translation such as BIH\PNAT =0A>=0A>>is applied in differ=
ent scenarios with NAT46. NAT46 has a little difficulty to =0A=0A>>implemen=
t. But now I mainly want to know whether it makes sense to research or =0A=
=0A>>deploy NAT46. I think NAT46 depend on the emerging IPv6-only server, b=
ut does =0A>>ISP or ICP need IPv6-only server considering the shortage of I=
Pv4?  =E4=BA=8E 2011-5-3 =0A=0A>>13:29, Dan Wing =E5=86=99=E9=81=93: =0A>>=
=0A>>>-----Original Message----- From: behave-bounces@ietf.org =0A>>>[mailt=
o:behave-bounces@ietf.org] On Behalf Of Behcet Sarikaya Sent: Monday, May =
=0A>>=0A>>>02, 2011 8:18 AM To: Iljitsch van Beijnum; buptnoc Cc: softwires=
@ietf.org; =0A>>>behave@ietf.org Subject: Re: [BEHAVE] ***SPAM*** 5.548 (5)=
 Is nat46 worth =0A>>>researching=EF=BC=9F  This is good point. But maybe t=
his should be discussed in =0A>>>Softwires list. =0A>>>=0A>>>NAT46 is in sc=
ope of BEHAVE, and is not in scope of SOFTWIRE.  The BEHAVE =0A>>>charter i=
s clear on that.  But I have not yet understood how or where we would =0A>=
=0A>>>see an IPv4-only client needing to access an IPv6-only server (that i=
s, a server =0A>>>=0A>>>with only an IPv6 address).  -d =0A>>>=0A>>________=
_______________________________________ Behave mailing list =0A>>Behave@iet=
f.org https://www.ietf.org/mailman/listinfo/behave  =0A>>

From iljitsch@muada.com  Tue May 10 09:33:05 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 64027E0833 for ; Tue, 10 May 2011 09:33:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.148
X-Spam-Level: 
X-Spam-Status: No, score=-102.148 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, SARE_SUB_ENC_UTF8=0.152, 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 EQQi3kisvKkl for ; Tue, 10 May 2011 09:33:04 -0700 (PDT)
Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id 270F4E0828 for ; Tue, 10 May 2011 09:33:03 -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 p4AGY0Yd082282 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 10 May 2011 18:34:03 +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: <128586.54187.qm@web111407.mail.gq1.yahoo.com>
Date: Tue, 10 May 2011 18:32:46 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <4DB95962.5090407@gmail.com>  <192669.64705.qm@web111411.mail.gq1.yahoo.com> <01df01cc0953$0c23a560$246af020$@com> <4DC0BDC5.8070402@gmail.com>  <4DC8C910.9040503@gmail.com> <128586.54187.qm@web111407.mail.gq1.yahoo.com>
To: Behcet Sarikaya 
X-Mailer: Apple Mail (2.1084)
Cc: "behave@ietf.orgWG WG" 
Subject: Re: [BEHAVE] =?utf-8?q?Is_nat46_worth_researching=EF=BC=9F?=
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, 10 May 2011 16:33:05 -0000

On 10 mei 2011, at 17:45, Behcet Sarikaya wrote:

> Remember one problem could be solved based on today's news:=20

> Skype could become IPv6 soon.

Note that simply making Skype IPv6-capable doesn't solve much: this only =
allows two people who both have IPv6 to talk to each other over IPv6. =
(As somehow IETF consensus occurred that IPv6 hosts should reside behind =
a stateful firewall, IPv6 to IPv6 could have some complexities of its =
own, too.)

For the purpose of transitioning from IPv4 to IPv6 there are four types =
of applications:

Client/server email-like
Client/server web-like
Peer-to-peer BitTorrent-like
Peer-to-peer VoIP-like

For the email-like applications once the one or two servers you talk to =
are dual stack the clients can become IPv6-only. For the web you need to =
upgrade ALL servers to dual stack before clients can become IPv6-only.

For BitTorrent-like you only need a few dual stack peers. As long as the =
IPv4 and IPv6 clouds overlap you're in business, because a given peer =
doesn't have to talk to a given other peer.

The trouble is VoIP-like. Here, any peer may want to talk to any other =
peer. So EVERYONE needs to be dual stack before it becomes possible to =
become IPv6-only.

So it would be very useful to make Skype and other similar applications =
work through NAT64. The trouble is of course that Skype doesn't use the =
DNS, so that won't happen the way things are now. But it shouldn't be =
extremely hard, because the main thing that's needed for this is =
knowledge of the Pref64. Hopefully people will use the well known one, =
and even without a standard mechanism for discovering it if otherwise, =
it's easy enough to roll your own by doing an AAAA lookup for something =
that only has an A record.=

From cb.list6@gmail.com  Tue May 10 09:44:56 2011
Return-Path: 
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE62E076D for ; Tue, 10 May 2011 09:44:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.826
X-Spam-Level: 
X-Spam-Status: No, score=-2.826 tagged_above=-999 required=5 tests=[AWL=0.321,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152]
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 SBJ5KcPt5RmU for ; Tue, 10 May 2011 09:44:55 -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 902ABE0693 for ; Tue, 10 May 2011 09:44:55 -0700 (PDT)
Received: by eye13 with SMTP id 13so2323196eye.31 for ; Tue, 10 May 2011 09:44:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=LJj47D4zYPaDH9/VytapBrX3nqH8sxlGd7OEa7YxJU4=; b=QCm7iC3g3sJZYSkry2qZBFA4N16WwhHrWEnfoAl4xqOjZB3C6j+ynh8xyiAxW3Bpg2 Z7uR8vmimlbcNGs7N44hGcehbJfRQJp6evb3vN4UcGFRFzjYyFHmCyackaiw1Vjb1Knf RXuXGZSk8Eh1MlksseWvUEvTH4EEDdIrbNJUY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=pMp9at7mPeyPuDnQi+aAlr5PiSP36bRU9loOSZRZDbFWyHtXWdgRCc+EZGp18Wv6kv WAsYj3SZbIlJL7F8oQ2aFeU5j+4lgGg/Hx/JtvV4CeIJXBFv7ZSlU0q81N6HkccfLZUE wxkAJbGiFdfJl2bcr+VMI4tLmLvCTmBmUStSM=
MIME-Version: 1.0
Received: by 10.14.17.129 with SMTP id j1mr3807132eej.121.1305045894058; Tue, 10 May 2011 09:44:54 -0700 (PDT)
Received: by 10.14.37.143 with HTTP; Tue, 10 May 2011 09:44:54 -0700 (PDT)
In-Reply-To: 
References: <4DB95962.5090407@gmail.com>  <192669.64705.qm@web111411.mail.gq1.yahoo.com> <01df01cc0953$0c23a560$246af020$@com> <4DC0BDC5.8070402@gmail.com>  <4DC8C910.9040503@gmail.com> <128586.54187.qm@web111407.mail.gq1.yahoo.com> 
Date: Tue, 10 May 2011 09:44:54 -0700
Message-ID: 
From: Cameron Byrne 
To: Iljitsch van Beijnum 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Behcet Sarikaya , "behave@ietf.orgWG WG" 
Subject: Re: [BEHAVE] =?utf-8?q?Is_nat46_worth_researching=EF=BC=9F?=
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, 10 May 2011 16:44:56 -0000

On Tue, May 10, 2011 at 9:32 AM, Iljitsch van Beijnum
 wrote:
> On 10 mei 2011, at 17:45, Behcet Sarikaya wrote:
>
>> Remember one problem could be solved based on today's news:
>
>> Skype could become IPv6 soon.
>
> Note that simply making Skype IPv6-capable doesn't solve much: this only =
allows two people who both have IPv6 to talk to each other over IPv6. (As s=
omehow IETF consensus occurred that IPv6 hosts should reside behind a state=
ful firewall, IPv6 to IPv6 could have some complexities of its own, too.)
>
> For the purpose of transitioning from IPv4 to IPv6 there are four types o=
f applications:
>
> Client/server email-like
> Client/server web-like
> Peer-to-peer BitTorrent-like
> Peer-to-peer VoIP-like
>
> For the email-like applications once the one or two servers you talk to a=
re dual stack the clients can become IPv6-only. For the web you need to upg=
rade ALL servers to dual stack before clients can become IPv6-only.
>
> For BitTorrent-like you only need a few dual stack peers. As long as the =
IPv4 and IPv6 clouds overlap you're in business, because a given peer doesn=
't have to talk to a given other peer.
>
> The trouble is VoIP-like. Here, any peer may want to talk to any other pe=
er. So EVERYONE needs to be dual stack before it becomes possible to become=
 IPv6-only.
>
> So it would be very useful to make Skype and other similar applications w=
ork through NAT64. The trouble is of course that Skype doesn't use the DNS,=
 so that won't happen the way things are now. But it shouldn't be extremely=
 hard, because the main thing that's needed for this is knowledge of the Pr=
ef64. Hopefully people will use the well known one, and even without a stan=
dard mechanism for discovering it if otherwise, it's easy enough to roll yo=
ur own by doing an AAAA lookup for something that only has an A record.
>

WKP does not scale well in large networks that require CGN arrays of
many NAT64 systems in every many major metropolitan areas.

Cameron


 _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave
>

From behcetsarikaya@yahoo.com  Tue May 10 10:02: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 8E776E0834 for ; Tue, 10 May 2011 10:02:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.082
X-Spam-Level: 
X-Spam-Status: No, score=-1.082 tagged_above=-999 required=5 tests=[AWL=-0.895, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_BL_SPAMCOP_NET=1.96, SARE_SUB_ENC_UTF8=0.152]
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 zFCiTqzxZXc8 for ; Tue, 10 May 2011 10:02:57 -0700 (PDT)
Received: from nm18-vm1.bullet.mail.ne1.yahoo.com (nm18-vm1.bullet.mail.ne1.yahoo.com [98.138.91.64]) by ietfa.amsl.com (Postfix) with SMTP id 64392E0800 for ; Tue, 10 May 2011 10:02:57 -0700 (PDT)
Received: from [98.138.90.57] by nm18.bullet.mail.ne1.yahoo.com with NNFMP; 10 May 2011 17:02:52 -0000
Received: from [98.138.89.252] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 10 May 2011 17:02:52 -0000
Received: from [127.0.0.1] by omp1044.mail.ne1.yahoo.com with NNFMP; 10 May 2011 17:02:52 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 797795.31249.bm@omp1044.mail.ne1.yahoo.com
Received: (qmail 2793 invoked by uid 60001); 10 May 2011 17:02:52 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1305046972; bh=kYmEwx6J/l5bkl2PyMcTR6qPPuWWCZkaoRYW97jdjK4=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=zamZ2DAYEHGBA97Iaf5RTW/awBK+MTX6LKhfQukU8WzK9BMkw79gQqYxraj5RyZyLowMCN1ZSRVkmOxs29nxhNbFrHAFT0SqC5+6YKe2+X5CoD5GGd0hOktOuruIzbjfyuMmpYw/+vgReo7ULqyBfGMa0FdjEIdo7x8cg3OshUw=
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:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=tVVlWJ8PuYU9MUas/eZ1VN3aOPSrouDbRYqft/VZYREtyUSoBpgmYocKDzx11+oFMbrL55ZrSJPR6hZDaNjeKe734wDYDvVKVf6tRt9c9IYqbWMOK+YcMtsUuJw1jDD1685frd1BhsxJgsgQuOxPpBalxvpWjNRQNWQDri6XbBk=;
Message-ID: <254910.92073.qm@web111412.mail.gq1.yahoo.com>
X-YMail-OSG: 7dIfkn0VM1lvzlAZflMsdSg56kBIyU.DfOe6s.3_v3WvKZj ThC2ZMyN_fxC7awzt3sb3O4Bu6aKdSTC0lzmejTD4v05mAPV6CgDFh9Fwd.K wxVF9W9bGTlZWXqppQYcUZPsCYwZiLI6n710H_Wgt2vbGAFwqL_d82giGe32 65HEjQeFrqhRBpg2Y02O9RmXjf3NjUrDKSUTeBwcQPhOYrxCvXjCobkzIR5k aIRsYtd8MZ9DNSl9cu439NltfENugue9GJpBjnbNEJLx5DRcAOJQOzbabpDH re_q7Rp17icdtpO6AMB1Zwc1GfHFjrcS.Mag2RCxnAYfqdHguqUjMw.PytGl .ZKtUEHal1akfLk49T4LkDgk6MuQ7RvoNiqOkQwMN_JnJ1K_nH0iGbjqJdUf syvtvfW5H4eGzRQ--
Received: from [206.16.17.212] by web111412.mail.gq1.yahoo.com via HTTP; Tue, 10 May 2011 10:02:52 PDT
X-Mailer: YahooMailRC/559 YahooMailWebService/0.8.110.299900
References: <4DB95962.5090407@gmail.com>  <192669.64705.qm@web111411.mail.gq1.yahoo.com> <01df01cc0953$0c23a560$246af020$@com> <4DC0BDC5.8070402@gmail.com>  <4DC8C910.9040503@gmail.com> <128586.54187.qm@web111407.mail.gq1.yahoo.com> 
Date: Tue, 10 May 2011 10:02:52 -0700 (PDT)
From: Behcet Sarikaya 
To: Iljitsch van Beijnum 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: "behave@ietf.orgWGWG" 
Subject: Re: [BEHAVE] =?utf-8?q?Is_nat46_worth_researching=EF=BC=9F?=
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Behcet Sarikaya 
List-Id: mailing list of BEHAVE IETF WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 May 2011 17:02:58 -0000

For my purposes, an IPv6 Skype would solve a lot of problems.=0AAs Gang sai=
d, operators are deploying IPv6 only networks and a popular =0Aapplication =
like Skype works there is a good thing.=0A=0AAnd I agree with Cameron, WKP6=
4 is not going to be that popular.=0A=0A=0A=0A=0A> On 10 mei 2011, at 17:45=
, Behcet Sarikaya wrote:=0A> =0A> > Remember one  problem could be solved b=
ased on today's news: =0A> =0A> > Skype could become  IPv6 soon.=0A> =0A> N=
ote that simply making Skype IPv6-capable doesn't solve much:  this only =
=0A>allows two people who both have IPv6 to talk to each other over IPv6.  =
(As =0A>somehow IETF consensus occurred that IPv6 hosts should reside behin=
d a  stateful =0A>firewall, IPv6 to IPv6 could have some complexities of it=
s own,  too.)=0A> =0A> For the purpose of transitioning from IPv4 to IPv6 t=
here are four  types of =0A>applications:=0A> =0A> Client/server email-like=
=0A> Client/server  web-like=0A> Peer-to-peer BitTorrent-like=0A> Peer-to-p=
eer VoIP-like=0A> =0A> For  the email-like applications once the one or two=
 servers you talk to are =0A>dual  stack the clients can become IPv6-only. =
For the web you need to upgrade =0A>ALL  servers to dual stack before clien=
ts can become IPv6-only.=0A> =0A> For  BitTorrent-like you only need a few =
dual stack peers. As long as the IPv4 =0A>and  IPv6 clouds overlap you're i=
n business, because a given peer doesn't have =0A>to  talk to a given other=
 peer.=0A> =0A> The trouble is VoIP-like. Here, any peer may  want to talk =
to any other peer. =0A>So EVERYONE needs to be dual stack before it  become=
s possible to become =0A>IPv6-only.=0A> =0A> So it would be very useful to =
make  Skype and other similar applications work =0A>through NAT64. The trou=
ble is of  course that Skype doesn't use the DNS, so that =0A>won't happen =
the way things are  now. But it shouldn't be extremely hard, =0A>because th=
e main thing that's needed  for this is knowledge of the Pref64. =0A>Hopefu=
lly people will use the well known  one, and even without a standard =0A>me=
chanism for discovering it if otherwise, it's  easy enough to roll your own=
 by =0A>doing an AAAA lookup for something that only has  an A record.=0A> =
_______________________________________________=0A> Behave  mailing list=0A=
> Behave@ietf.org=0A> https://www.ietf.org/mailman/listinfo/behave=0A> 

From cb.list6@gmail.com  Tue May 10 15:21: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 B6A16E0913 for ; Tue, 10 May 2011 15:21:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.068
X-Spam-Level: 
X-Spam-Status: No, score=-3.068 tagged_above=-999 required=5 tests=[AWL=0.531,  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 Alfy1zRximub for ; Tue, 10 May 2011 15:21:48 -0700 (PDT)
Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 673E4E06D9 for ; Tue, 10 May 2011 15:21:47 -0700 (PDT)
Received: by ewy19 with SMTP id 19so2415315ewy.31 for ; Tue, 10 May 2011 15:21:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=e5ublhmTewnvMjndq7yYj64Qyivhi30h7Q1sWs+0psY=; b=BHl0UVnByiXwX+hfoc4sQL+748DvnOMch4Q1JX5J3m1FGAJgSDRGoR/GyFQFTjdRqo P9GwNBuxNi4DlHELhFlctJit4mdmX4BmWLJy5m05gendJiOuGY2oz4kBo4/1hXYCA+7m li5LvbnkZl8gQxsPljFaPFxMwMusseMvJ3SRs=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Jk07eIXF9Zev/oh/oKp6p3kJbtlTsTnyHNpg5cu01dABLaCMGu1mDL+s+IWGoEZf7T nOaAYpEoasGVq/zJKIV2XFIvDByWbSMUgOKmVSipdfP6Klw0akAXRKJjFL53lY1TjVzu wuYf7thQl1ovHYN27Udm5iRvq5BrVlv5VzcF4=
MIME-Version: 1.0
Received: by 10.14.123.205 with SMTP id v53mr4074733eeh.217.1305066105722; Tue, 10 May 2011 15:21:45 -0700 (PDT)
Received: by 10.14.37.143 with HTTP; Tue, 10 May 2011 15:21:45 -0700 (PDT)
In-Reply-To: <035a01cc0b8a$5311ce50$f9356af0$@com>
References: <035a01cc0b8a$5311ce50$f9356af0$@com>
Date: Tue, 10 May 2011 15:21:45 -0700
Message-ID: 
From: Cameron Byrne 
To: Dan Wing 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: jouni.nospam@gmail.com, behave@ietf.org, behave-chairs@tools.ietf.org
Subject: Re: [BEHAVE] adoption of learn analysis and DNS-based NAT64 prefix discovery
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, 10 May 2011 22:21:49 -0000

On Thu, May 5, 2011 at 6:10 PM, Dan Wing  wrote:
> At IETF80, we appeared to have reach regarding BEHAVE's milestone "Apr 20=
11
> - Submit to IESG: avoiding NAT64 with dual-stack host for local networks
> (std)". =A0Excerpt from the minutes is below. =A0Under this milestone, it=
 seems
> valuable to publish two documents: =A0one which analyzes the various
> approaches, and another that details the specific recommended approach.
>
> To that end, please provide feedback to behave@ietf.org on adopting the
> following two documents as working group documents:
>
> 1. =A0draft-korhonen-behave-nat64-learn-analysis, to be informational
> =A0 =A0http://tools.ietf.org/html/draft-korhonen-behave-nat64-learn-analy=
sis-02
>

I support this draft and believe moving forward with the conclusion of
publishing the Well-Known DNS Name heuristic-based method is a great
way to get a quick solution in place.

One nit -- in first paragraph s/analyses/analyze

> 2. =A0draft-savolainen-heuristic-nat64-discovery, likely to be standards =
track
>
> =A0 =A0or possibly informational
> =A0 =A0http://tools.ietf.org/html/draft-savolainen-heuristic-nat64-discov=
ery-01
>

I also support this draft as being important work to move forward and
for IANA to host a well known name.

Cameron

From marka@isc.org  Tue May 10 16:13: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 351D5E0744 for ; Tue, 10 May 2011 16:13:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.867
X-Spam-Level: 
X-Spam-Status: No, score=-1.867 tagged_above=-999 required=5 tests=[AWL=0.280,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152]
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 jFqYtDPDg9Ny for ; Tue, 10 May 2011 16:13:50 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id A26FCE0738 for ; Tue, 10 May 2011 16:13:49 -0700 (PDT)
Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id D4105C948E; Tue, 10 May 2011 22:14:46 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 6CE27216C31; Tue, 10 May 2011 22:14:46 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id DC630EA1198; Wed, 11 May 2011 08:15:10 +1000 (EST)
To: Iljitsch van Beijnum 
From: Mark Andrews 
References: <4DB95962.5090407@gmail.com>  <192669.64705.qm@web111411.mail.gq1.yahoo.com> <01df01cc0953$0c23a560$246af020$@com> <4DC0BDC5.8070402@gmail.com>  <4DC8C910.9040503@gmail.com> <128586.54187.qm@web111407.mail.gq1.yahoo.com> 
In-reply-to: Your message of "Tue, 10 May 2011 18:32:46 +0200." 
Date: Wed, 11 May 2011 08:15:10 +1000
Message-Id: <20110510221510.DC630EA1198@drugs.dv.isc.org>
Cc: Behcet Sarikaya , "behave@ietf.orgWG WG" 
Subject: Re: [BEHAVE] =?utf-8?q?Is_nat46_worth_researching=EF=BC=9F?=
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, 10 May 2011 23:13:51 -0000

In message , Iljitsch van Beijn
um writes:
> On 10 mei 2011, at 17:45, Behcet Sarikaya wrote:
> 
> > Remember one problem could be solved based on today's news: 
> 
> > Skype could become IPv6 soon.
> 
> Note that simply making Skype IPv6-capable doesn't solve much: this only allo
> ws two people who both have IPv6 to talk to each other over IPv6. (As somehow
>  IETF consensus occurred that IPv6 hosts should reside behind a stateful fire
> wall, IPv6 to IPv6 could have some complexities of its own, too.)
> 
> For the purpose of transitioning from IPv4 to IPv6 there are four types of ap
> plications:
> 
> Client/server email-like
> Client/server web-like
> Peer-to-peer BitTorrent-like
> Peer-to-peer VoIP-like
> 
> For the email-like applications once the one or two servers you talk to are d
> ual stack the clients can become IPv6-only. For the web you need to upgrade A
> LL servers to dual stack before clients can become IPv6-only.
> 
> For BitTorrent-like you only need a few dual stack peers. As long as the IPv4
>  and IPv6 clouds overlap you're in business, because a given peer doesn't hav
> e to talk to a given other peer.
> 
> The trouble is VoIP-like. Here, any peer may want to talk to any other peer. 
> So EVERYONE needs to be dual stack before it becomes possible to become IPv6-
> only.

No.  Most people only talk to a small set of people.  As long as the set of
people you talk to have IPv6 support you can go IPv6 only.

Perfect is the enemy of good enough.

> So it would be very useful to make Skype and other similar applications work 
> through NAT64. The trouble is of course that Skype doesn't use the DNS, so th
> at won't happen the way things are now. But it shouldn't be extremely hard, b
> ecause the main thing that's needed for this is knowledge of the Pref64. Hope
> fully people will use the well known one, and even without a standard mechani
> sm for discovering it if otherwise, it's easy enough to roll your own by doin
> g an AAAA lookup for something that only has an A record.
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From xing@cernet.edu.cn  Fri May 13 19:26: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 A5139E06F5 for ; Fri, 13 May 2011 19:26:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -97.962
X-Spam-Level: 
X-Spam-Status: No, score=-97.962 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FH_HAS_XAIMC=2.696, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152, 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 KVLFIVTrFIEG for ; Fri, 13 May 2011 19:26:51 -0700 (PDT)
Received: from cernet.edu.cn (sea.net.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with SMTP id B56F6E062A for ; Fri, 13 May 2011 19:26:48 -0700 (PDT)
Received: from [127.0.0.1]([125.34.44.97]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm54dce13b6; Sat, 14 May 2011 10:26:46 +0800
Message-ID: <4DCDE85D.3000705@cernet.edu.cn>
Date: Sat, 14 May 2011 10:26:37 +0800
From: Xing Li 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; zh-CN; rv:1.9.2.14) Gecko/20110221 Thunderbird/3.1.8
MIME-Version: 1.0
To: Dan Wing 
References: <4DB95962.5090407@gmail.com>						<626885.40271.qm@web111405.mail.gq1.yahoo.com>		<858570.52926.qm@web111403.mail.gq1.yahoo.com>	 <069b01cc0e98$49507810$dbf16830$@com>
In-Reply-To: <069b01cc0e98$49507810$dbf16830$@com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-AIMC-AUTH: xing
X-AIMC-MAILFROM: xing@cernet.edu.cn
X-AIMC-Msg-ID: qdE9EV0B
Cc: 'Cameron Byrne' , behave@ietf.org, 'Behcet Sarikaya' 
Subject: Re: [BEHAVE] =?utf-8?q?Is_nat46_worth_researching=EF=BC=9F?=
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, 14 May 2011 02:26:51 -0000

于 2011/5/10 6:27, Dan Wing 写é“:
>> No, NAT64D is not documented in the IETF.
>>
>> I am told there is no appetite for something that looks like NAT464 in
>> the IETF, even though it solves a real problem.
> The reason there is no appetite in the IETF is it removes the
> incentive for the application to support IPv6.  Which means the
> transition technology (NAT464) persists in networks forever,
> becoming a permanent cost to network operation.

The tunneling approaches also remove the incentive for the application 
to support IPv6.

Regards,

xing

> -d
>
>> BIH is close, but it explicitly excludes the use in combination with
>> NAT64 and requires DNS interactions .... so it will not work for
>> applications like Skype or anything else that uses IPv4 referrals.
>>
>> Cameron
>>
>>> Regards,
>>>
>>> Behcet
>>>
>>>
>> _______________________________________________
>> Behave mailing list
>> Behave@ietf.org
>> https://www.ietf.org/mailman/listinfo/behave
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave


From mohamed.boucadair@orange-ftgroup.com  Mon May 16 07:03: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 8C011E0741 for ; Mon, 16 May 2011 07:03:30 -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=[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 VAAInYThWvQz for ; Mon, 16 May 2011 07:03:29 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id 54C2BE071C for ; Mon, 16 May 2011 07:03:29 -0700 (PDT)
Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 890DB3741E9; Mon, 16 May 2011 16:03:27 +0200 (CEST)
Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 56FF2158059; Mon, 16 May 2011 16:03:27 +0200 (CEST)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Mon, 16 May 2011 16:03:27 +0200
From: 
To: Xing Li , Dan Wing 
Date: Mon, 16 May 2011 16:03:26 +0200
Thread-Topic: [BEHAVE] WGLC, draft-ietf-behave-64-analysis-02
Thread-Index: AcwK8BXH0o4IKzxjSIW/bZIenCktqwI4crGQ
Message-ID: <94C682931C08B048B7A8645303FDC9F33E4DF86CBE@PUEXCB1B.nanterre.francetelecom.fr>
References: <088001cc0a83$a65edc90$f31c95b0$@com> <4DC2478A.2060709@cernet.edu.cn>
In-Reply-To: <4DC2478A.2060709@cernet.edu.cn>
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_94C682931C08B048B7A8645303FDC9F33E4DF86CBEPUEXCB1Bnante_"
MIME-Version: 1.0
X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.5.16.115418
Cc: "draft-ietf-behave-64-analysis@tools.ietf.org" , "behave@ietf.org" , 'Behave Chairs' 
Subject: Re: [BEHAVE] WGLC, draft-ietf-behave-64-analysis-02
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 May 2011 14:03:30 -0000

--_000_94C682931C08B048B7A8645303FDC9F33E4DF86CBEPUEXCB1Bnante_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

RGVhciBYaW5nLA0KDQpUaGFuayB5b3UgZm9yIHRoZSBjb21tZW50cy4NCg0KSSB1cGRhdGVkIG15
IGxvY2FsIGNvcHkgd2l0aCB5b3VyIHByb3Bvc2VkIGNoYW5nZXMuDQoNCkNoZWVycywNCk1lZA0K
DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRGUgOiBYaW5nIExpIFttYWlsdG86
eGluZ0BjZXJuZXQuZWR1LmNuXQ0KRW52b3nDqSA6IGpldWRpIDUgbWFpIDIwMTEgMDg6NDYNCsOA
IDogRGFuIFdpbmcNCkNjIDogYmVoYXZlQGlldGYub3JnOyBkcmFmdC1pZXRmLWJlaGF2ZS02NC1h
bmFseXNpc0B0b29scy5pZXRmLm9yZzsgJ0JlaGF2ZSBDaGFpcnMnDQpPYmpldCA6IFJlOiBbQkVI
QVZFXSBXR0xDLCBkcmFmdC1pZXRmLWJlaGF2ZS02NC1hbmFseXNpcy0wMg0KDQrkuo4gMjAxMS81
LzUgMTo0OSwgRGFuIFdpbmcg5YaZ6YGTOg0KDQpXZSBhcmUgc3RhcnRpbmcgYSB0d28gd2VlayBX
R0xDIGZvciAiQW5hbHlzaXMgb2YgNjQgVHJhbnNsYXRpb24iLA0KaHR0cDovL3d3dy5pZXRmLm9y
Zy9pZC9kcmFmdC1pZXRmLWJlaGF2ZS02NC1hbmFseXNpcy0wMi50eHQsIHRvIGZ1bGZpbGwNCkJF
SEFWRSdzIG1pbGVzdG9uZSAiRmViIDIwMTEgLSBTdWJtaXQgdG8gSUVTRzogQW5hbHlzaXMgb2Yg
TkFULVBUDQpjb25zaWRlcmF0aW9ucyB3aXRoIElQdjYvSVB2NCB0cmFuc2xhdGlvbiAoaW5mbyki
LiAgUGxlYXNlIHNlbmQgc3Vic3RhbnRpdmUNCmNvbW1lbnRzIHRvIHRoZSBsaXN0LCBhbmQgaWYg
cG9zc2libGUgc2VuZCBlZGl0aW5nIHN1Z2dlc3Rpb25zIGp1c3QgdG8gdGhlDQphdXRob3JzLg0K
DQpUaGUgV0dMQyBlbmRzIG9uIFdlZG5lc2RheSwgTWF5IDE4Lg0KDQoNClNpbmNlIHRoaXMgZG9j
dW1lbnQgY2xlYXJseSBzdGF0ZXM6DQoNCiAgIFRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50IGRv
ZXMgbm90IGluY2x1ZGUgc3RhdGVsZXNzIHRyYW5zbGF0aW9uLg0KDQpJIHN1Z2dlc3QgdG8gcHV0
IHdvcmQgInN0YXRlZnVsIiBpbiB0aGUgdGl0bGUgb2YgdGhpcyBkb2N1bWVudCAoYXMgd2VsbCBh
cyBpbiB0aGUgYWJzdHJhY3QpLg0KDQpUdGlsZTogIEFuYWx5c2lzIG9mIFN0YXRlZnVsIDY0IFRy
YW5zbGF0aW9uDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBeXl5eXl5eDQpBYnN0cmFj
dDoNCiAgIER1ZSB0byBzcGVjaWZpYyBwcm9ibGVtcywgTkFULVBUIHdhcyBkZXByZWNhdGVkIGJ5
IHRoZSBJRVRGIGFzIGENCiAgIG1lY2hhbmlzbSB0byBwZXJmb3JtIElQdjYtSVB2NCB0cmFuc2xh
dGlvbi4gIFNpbmNlIHRoZW4sIG5ldyBlZmZvcnRzDQogICBoYXZlIGJlZW4gdW5kZXJ0YWtlbiB3
aXRoaW4gSUVURiB0byBzdGFuZGFyZGl6ZSBhbHRlcm5hdGl2ZQ0KICAgbWVjaGFuaXNtcyB0byBw
ZXJmb3JtIElQdjYtSVB2NCB0cmFuc2xhdGlvbi4gIFRoaXMgZG9jdW1lbnQgZXZhbHVhdGVzDQog
ICBob3cgdGhlIG5ldyBzdGF0ZWZ1bCB0cmFuc2xhdGlvbiBtZWNoYW5pc21zIGF2b2lkIHRoZSBw
cm9ibGVtcyB0aGF0IGNhdXNlZCB0aGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgXl5eXl5e
Xg0KICAgSUVURiB0byBkZXByZWNhdGUgTkFULVBULg0KDQpSRkM2MTQ1IGlzIGFsc28gcGFydCBv
ZiB0aGUgc3RhdGVmdWwgdHJhbnNsYXRpb24gc3RhbmRhcmRzLCBwbGVhc2UgY2l0ZSB0aGF0IFJG
QyBpbiBTZWN0aW9uIDEuMS4NCg0KUmVnYXJkcywNCg0KeGluZw0KDQoNCg0KLWQNCg0KDQpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQmVoYXZlIG1haWxp
bmcgbGlzdA0KQmVoYXZlQGlldGYub3JnPG1haWx0bzpCZWhhdmVAaWV0Zi5vcmc+DQpodHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2JlaGF2ZQ0KDQoNCg0KDQo=

--_000_94C682931C08B048B7A8645303FDC9F33E4DF86CBEPUEXCB1Bnante_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u
YWwvL0VOIj4NCjxIVE1MPjxIRUFEPjxUSVRMRT48L1RJVExFPg0KPE1FVEEgaHR0cC1lcXVpdj1D
b250ZW50LVR5cGUgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIGNv
bnRlbnQ9Ik1TSFRNTCA2LjAwLjI5MDAuNTUxMiIgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJP
RFkgdGV4dD0jMDAwMDAwIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0
PjxTUEFOIGNsYXNzPTM3NDIyMDIxNC0xNjA1MjAxMT48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyIg
DQpjb2xvcj0jMDAwMGZmIHNpemU9Mj5EZWFyIFhpbmcsPC9GT05UPjwvU1BBTj48L0RJVj4NCjxE
SVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTM3NDIyMDIxNC0xNjA1MjAxMT48Rk9O
VCBmYWNlPSJDb3VyaWVyIE5ldyIgDQpjb2xvcj0jMDAwMGZmIHNpemU9Mj48L0ZPTlQ+PC9TUEFO
PiZuYnNwOzwvRElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9Mzc0MjIw
MjE0LTE2MDUyMDExPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiANCmNvbG9yPSMwMDAwZmYgc2l6
ZT0yPlRoYW5rIHlvdSBmb3IgdGhlIGNvbW1lbnRzLjwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElW
IGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz0zNzQyMjAyMTQtMTYwNTIwMTE+PEZPTlQg
ZmFjZT0iQ291cmllciBOZXciIA0KY29sb3I9IzAwMDBmZiBzaXplPTI+PC9GT05UPjwvU1BBTj4m
bmJzcDs8L0RJVj4NCjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTM3NDIyMDIx
NC0xNjA1MjAxMT48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyIgDQpjb2xvcj0jMDAwMGZmIHNpemU9
Mj5JIHVwZGF0ZWQgbXkgbG9jYWwgY29weSB3aXRoIHlvdXIgcHJvcG9zZWQgDQpjaGFuZ2VzLjwv
Rk9OVD48L1NQQU4+PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz0z
NzQyMjAyMTQtMTYwNTIwMTE+PEZPTlQgZmFjZT0iQ291cmllciBOZXciIA0KY29sb3I9IzAwMDBm
ZiBzaXplPTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCjxESVYgZGlyPWx0ciBhbGlnbj1s
ZWZ0PjxTUEFOIGNsYXNzPTM3NDIyMDIxNC0xNjA1MjAxMT48Rk9OVCBmYWNlPSJDb3VyaWVyIE5l
dyIgDQpjb2xvcj0jMDAwMGZmIHNpemU9Mj5DaGVlcnMsPC9GT05UPjwvU1BBTj48L0RJVj4NCjxE
SVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTM3NDIyMDIxNC0xNjA1MjAxMT48Rk9O
VCBmYWNlPSJDb3VyaWVyIE5ldyIgDQpjb2xvcj0jMDAwMGZmIHNpemU9Mj5NZWQ8L0ZPTlQ+PC9T
UEFOPjwvRElWPjxCUj4NCjxESVYgY2xhc3M9T3V0bG9va01lc3NhZ2VIZWFkZXIgbGFuZz1mciBk
aXI9bHRyIGFsaWduPWxlZnQ+DQo8SFIgdGFiSW5kZXg9LTE+DQo8Rk9OVCBmYWNlPVRhaG9tYSBz
aXplPTI+PEI+RGUmbmJzcDs6PC9CPiBYaW5nIExpIFttYWlsdG86eGluZ0BjZXJuZXQuZWR1LmNu
XSANCjxCUj48Qj5FbnZvecOpJm5ic3A7OjwvQj4gamV1ZGkgNSBtYWkgMjAxMSAwODo0NjxCUj48
Qj7DgCZuYnNwOzo8L0I+IERhbiANCldpbmc8QlI+PEI+Q2MmbmJzcDs6PC9CPiBiZWhhdmVAaWV0
Zi5vcmc7IA0KZHJhZnQtaWV0Zi1iZWhhdmUtNjQtYW5hbHlzaXNAdG9vbHMuaWV0Zi5vcmc7ICdC
ZWhhdmUgDQpDaGFpcnMnPEJSPjxCPk9iamV0Jm5ic3A7OjwvQj4gUmU6IFtCRUhBVkVdIFdHTEMs
IA0KZHJhZnQtaWV0Zi1iZWhhdmUtNjQtYW5hbHlzaXMtMDI8QlI+PC9GT05UPjxCUj48L0RJVj4N
CjxESVY+PC9ESVY+5LqOIDIwMTEvNS81IDE6NDksIERhbiBXaW5nIOWGmemBkzogDQo8QkxPQ0tR
VU9URSBjaXRlPW1pZDowODgwMDFjYzBhODMkYTY1ZWRjOTAkZjMxYzk1YjAkQGNvbSB0eXBlPSJj
aXRlIj48UFJFIHdyYXA9IiI+V2UgYXJlIHN0YXJ0aW5nIGEgdHdvIHdlZWsgV0dMQyBmb3IgIkFu
YWx5c2lzIG9mIDY0IFRyYW5zbGF0aW9uIiwNCjxBIGNsYXNzPW1vei10eHQtbGluay1mcmVldGV4
dCBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWlldGYtYmVoYXZlLTY0LWFuYWx5
c2lzLTAyLnR4dCI+aHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLWJlaGF2ZS02NC1h
bmFseXNpcy0wMi50eHQ8L0E+LCB0byBmdWxmaWxsDQpCRUhBVkUncyBtaWxlc3RvbmUgIkZlYiAy
MDExIC0gU3VibWl0IHRvIElFU0c6IEFuYWx5c2lzIG9mIE5BVC1QVA0KY29uc2lkZXJhdGlvbnMg
d2l0aCBJUHY2L0lQdjQgdHJhbnNsYXRpb24gKGluZm8pIi4gIFBsZWFzZSBzZW5kIHN1YnN0YW50
aXZlDQpjb21tZW50cyB0byB0aGUgbGlzdCwgYW5kIGlmIHBvc3NpYmxlIHNlbmQgZWRpdGluZyBz
dWdnZXN0aW9ucyBqdXN0IHRvIHRoZQ0KYXV0aG9ycy4NCg0KVGhlIFdHTEMgZW5kcyBvbiBXZWRu
ZXNkYXksIE1heSAxOC4NCjwvUFJFPjwvQkxPQ0tRVU9URT48QlI+U2luY2UgdGhpcyBkb2N1bWVu
dCBjbGVhcmx5IHN0YXRlczo8QlI+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPHc6V29yZERv
Y3VtZW50Pg0KICA8dzpWaWV3Pk5vcm1hbDwvdzpWaWV3Pg0KICA8dzpab29tPjA8L3c6Wm9vbT4N
CiAgPHc6UHVuY3R1YXRpb25LZXJuaW5nLz4NCiAgPHc6RHJhd2luZ0dyaWRWZXJ0aWNhbFNwYWNp
bmc+Ny44ICYjMzA5MTc7PC93OkRyYXdpbmdHcmlkVmVydGljYWxTcGFjaW5nPg0KICA8dzpEaXNw
bGF5SG9yaXpvbnRhbERyYXdpbmdHcmlkRXZlcnk+MDwvdzpEaXNwbGF5SG9yaXpvbnRhbERyYXdp
bmdHcmlkRXZlcnk+DQogIDx3OkRpc3BsYXlWZXJ0aWNhbERyYXdpbmdHcmlkRXZlcnk+MjwvdzpE
aXNwbGF5VmVydGljYWxEcmF3aW5nR3JpZEV2ZXJ5Pg0KICA8dzpWYWxpZGF0ZUFnYWluc3RTY2hl
bWFzLz4NCiAgPHc6U2F2ZUlmWE1MSW52YWxpZD5mYWxzZTwvdzpTYXZlSWZYTUxJbnZhbGlkPg0K
ICA8dzpJZ25vcmVNaXhlZENvbnRlbnQ+ZmFsc2U8L3c6SWdub3JlTWl4ZWRDb250ZW50Pg0KICA8
dzpBbHdheXNTaG93UGxhY2Vob2xkZXJUZXh0PmZhbHNlPC93OkFsd2F5c1Nob3dQbGFjZWhvbGRl
clRleHQ+DQogIDx3OkNvbXBhdGliaWxpdHk+DQogICA8dzpTcGFjZUZvclVMLz4NCiAgIDx3OkJh
bGFuY2VTaW5nbGVCeXRlRG91YmxlQnl0ZVdpZHRoLz4NCiAgIDx3OkRvTm90TGVhdmVCYWNrc2xh
c2hBbG9uZS8+DQogICA8dzpVTFRyYWlsU3BhY2UvPg0KICAgPHc6RG9Ob3RFeHBhbmRTaGlmdFJl
dHVybi8+DQogICA8dzpBZGp1c3RMaW5lSGVpZ2h0SW5UYWJsZS8+DQogICA8dzpCcmVha1dyYXBw
ZWRUYWJsZXMvPg0KICAgPHc6U25hcFRvR3JpZEluQ2VsbC8+DQogICA8dzpXcmFwVGV4dFdpdGhQ
dW5jdC8+DQogICA8dzpVc2VBc2lhbkJyZWFrUnVsZXMvPg0KICAgPHc6RG9udEdyb3dBdXRvZml0
Lz4NCiAgIDx3OlVzZUZFTGF5b3V0Lz4NCiAgPC93OkNvbXBhdGliaWxpdHk+DQogIDx3OkJyb3dz
ZXJMZXZlbD5NaWNyb3NvZnRJbnRlcm5ldEV4cGxvcmVyNDwvdzpCcm93c2VyTGV2ZWw+DQogPC93
OldvcmREb2N1bWVudD4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s
Pg0KIDx3OkxhdGVudFN0eWxlcyBEZWZMb2NrZWRTdGF0ZT0iZmFsc2UiIExhdGVudFN0eWxlQ291
bnQ9IjE1NiI+DQogPC93OkxhdGVudFN0eWxlcz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg
Z3RlIG1zbyAxMF0+DQo8c3R5bGU+DQogLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCiB0YWJsZS5N
c29Ob3JtYWxUYWJsZQ0KCXttc28tc3R5bGUtbmFtZTomIzI2MjIyOyYjMzY4OTA7JiMzNDkyMDsm
IzI2Njg0OzsNCgltc28tdHN0eWxlLXJvd2JhbmQtc2l6ZTowOw0KCW1zby10c3R5bGUtY29sYmFu
ZC1zaXplOjA7DQoJbXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXBhcmVudDoiIjsN
Cgltc28tcGFkZGluZy1hbHQ6MGNtIDUuNHB0IDBjbSA1LjRwdDsNCgltc28tcGFyYS1tYXJnaW46
MGNtOw0KCW1zby1wYXJhLW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgltc28tcGFnaW5hdGlvbjp3
aWRvdy1vcnBoYW47DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3
IFJvbWFuIjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNCglt
c28tYW5zaS1sYW5ndWFnZTojMDQwMDsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTojMDQwMDsNCglt
c28tYmlkaS1sYW5ndWFnZTojMDQwMDt9DQo8L3N0eWxlPg0KPCFbZW5kaWZdLS0+DQo8UCBjbGFz
cz1Nc29QbGFpblRleHQ+PFNQQU4gbGFuZz1FTi1VUz48U1BBTj4mbmJzcDsmbmJzcDsgPC9TUEFO
PlRoZSBzY29wZSBvZiANCnRoaXMgZG9jdW1lbnQgZG9lcyBub3QgaW5jbHVkZSBzdGF0ZWxlc3Mg
dHJhbnNsYXRpb24uPC9TUEFOPjwvUD5JIHN1Z2dlc3QgdG8gcHV0IA0Kd29yZCAic3RhdGVmdWwi
IGluIHRoZSB0aXRsZSBvZiB0aGlzIGRvY3VtZW50IChhcyB3ZWxsIGFzIGluIHRoZSANCmFic3Ry
YWN0KS48QlI+PEJSPlR0aWxlOiZuYnNwOyBBbmFseXNpcyBvZiBTdGF0ZWZ1bCA2NCANClRyYW5z
bGF0aW9uPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyANCl5eXl5eXl48QlI+PFNQQU4gbGFuZz1FTi1VUz5BYnN0cmFjdDo8L1NQ
QU4+PEJSPiZuYnNwOyZuYnNwOyBEdWUgdG8gc3BlY2lmaWMgDQpwcm9ibGVtcywgTkFULVBUIHdh
cyBkZXByZWNhdGVkIGJ5IHRoZSBJRVRGIGFzIGE8QlI+Jm5ic3A7Jm5ic3A7IG1lY2hhbmlzbSB0
byANCnBlcmZvcm0gSVB2Ni1JUHY0IHRyYW5zbGF0aW9uLiZuYnNwOyBTaW5jZSB0aGVuLCBuZXcg
ZWZmb3J0czxCUj4mbmJzcDsmbmJzcDsgDQpoYXZlIGJlZW4gdW5kZXJ0YWtlbiB3aXRoaW4gSUVU
RiB0byBzdGFuZGFyZGl6ZSBhbHRlcm5hdGl2ZTxCUj4mbmJzcDsmbmJzcDsgDQptZWNoYW5pc21z
IHRvIHBlcmZvcm0gSVB2Ni1JUHY0IHRyYW5zbGF0aW9uLiZuYnNwOyBUaGlzIGRvY3VtZW50IA0K
ZXZhbHVhdGVzPEJSPiZuYnNwOyZuYnNwOyBob3cgdGhlIG5ldyBzdGF0ZWZ1bCB0cmFuc2xhdGlv
biBtZWNoYW5pc21zIGF2b2lkIHRoZSANCnByb2JsZW1zIHRoYXQgY2F1c2VkIA0KdGhlPEJSPiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCl5eXl5eXl48QlI+Jm5ic3A7Jm5i
c3A7IElFVEYgdG8gZGVwcmVjYXRlIE5BVC1QVC48QlI+PEJSPlJGQzYxNDUgaXMgYWxzbyBwYXJ0
IG9mIA0KdGhlIHN0YXRlZnVsIHRyYW5zbGF0aW9uIHN0YW5kYXJkcywgcGxlYXNlIGNpdGUgdGhh
dCBSRkMgaW48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8dzpXb3JkRG9jdW1lbnQ+DQogIDx3
OlZpZXc+Tm9ybWFsPC93OlZpZXc+DQogIDx3Olpvb20+MDwvdzpab29tPg0KICA8dzpQdW5jdHVh
dGlvbktlcm5pbmcvPg0KICA8dzpEcmF3aW5nR3JpZFZlcnRpY2FsU3BhY2luZz43LjggJiMzMDkx
Nzs8L3c6RHJhd2luZ0dyaWRWZXJ0aWNhbFNwYWNpbmc+DQogIDx3OkRpc3BsYXlIb3Jpem9udGFs
RHJhd2luZ0dyaWRFdmVyeT4wPC93OkRpc3BsYXlIb3Jpem9udGFsRHJhd2luZ0dyaWRFdmVyeT4N
CiAgPHc6RGlzcGxheVZlcnRpY2FsRHJhd2luZ0dyaWRFdmVyeT4yPC93OkRpc3BsYXlWZXJ0aWNh
bERyYXdpbmdHcmlkRXZlcnk+DQogIDx3OlZhbGlkYXRlQWdhaW5zdFNjaGVtYXMvPg0KICA8dzpT
YXZlSWZYTUxJbnZhbGlkPmZhbHNlPC93OlNhdmVJZlhNTEludmFsaWQ+DQogIDx3Oklnbm9yZU1p
eGVkQ29udGVudD5mYWxzZTwvdzpJZ25vcmVNaXhlZENvbnRlbnQ+DQogIDx3OkFsd2F5c1Nob3dQ
bGFjZWhvbGRlclRleHQ+ZmFsc2U8L3c6QWx3YXlzU2hvd1BsYWNlaG9sZGVyVGV4dD4NCiAgPHc6
Q29tcGF0aWJpbGl0eT4NCiAgIDx3OlNwYWNlRm9yVUwvPg0KICAgPHc6QmFsYW5jZVNpbmdsZUJ5
dGVEb3VibGVCeXRlV2lkdGgvPg0KICAgPHc6RG9Ob3RMZWF2ZUJhY2tzbGFzaEFsb25lLz4NCiAg
IDx3OlVMVHJhaWxTcGFjZS8+DQogICA8dzpEb05vdEV4cGFuZFNoaWZ0UmV0dXJuLz4NCiAgIDx3
OkFkanVzdExpbmVIZWlnaHRJblRhYmxlLz4NCiAgIDx3OkJyZWFrV3JhcHBlZFRhYmxlcy8+DQog
ICA8dzpTbmFwVG9HcmlkSW5DZWxsLz4NCiAgIDx3OldyYXBUZXh0V2l0aFB1bmN0Lz4NCiAgIDx3
OlVzZUFzaWFuQnJlYWtSdWxlcy8+DQogICA8dzpEb250R3Jvd0F1dG9maXQvPg0KICAgPHc6VXNl
RkVMYXlvdXQvPg0KICA8L3c6Q29tcGF0aWJpbGl0eT4NCiAgPHc6QnJvd3NlckxldmVsPk1pY3Jv
c29mdEludGVybmV0RXhwbG9yZXI0PC93OkJyb3dzZXJMZXZlbD4NCiA8L3c6V29yZERvY3VtZW50
Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPHc6TGF0ZW50
U3R5bGVzIERlZkxvY2tlZFN0YXRlPSJmYWxzZSIgTGF0ZW50U3R5bGVDb3VudD0iMTU2Ij4NCiA8
L3c6TGF0ZW50U3R5bGVzPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDEwXT4N
CjxzdHlsZT4NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHRhYmxlLk1zb05vcm1hbFRhYmxl
DQoJe21zby1zdHlsZS1uYW1lOiYjMjYyMjI7JiMzNjg5MDsmIzM0OTIwOyYjMjY2ODQ7Ow0KCW1z
by10c3R5bGUtcm93YmFuZC1zaXplOjA7DQoJbXNvLXRzdHlsZS1jb2xiYW5kLXNpemU6MDsNCglt
c28tc3R5bGUtbm9zaG93OnllczsNCgltc28tc3R5bGUtcGFyZW50OiIiOw0KCW1zby1wYWRkaW5n
LWFsdDowY20gNS40cHQgMGNtIDUuNHB0Ow0KCW1zby1wYXJhLW1hcmdpbjowY207DQoJbXNvLXBh
cmEtbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsN
Cglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KCW1z
by1mYXJlYXN0LWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KCW1zby1hbnNpLWxhbmd1
YWdlOiMwNDAwOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOiMwNDAwOw0KCW1zby1iaWRpLWxhbmd1
YWdlOiMwNDAwO30NCjwvc3R5bGU+DQo8IVtlbmRpZl0tLT4gPFNQQU4gbGFuZz1FTi1VUz5TZWN0
aW9uIA0KMS4xLjxTUEFOPjwvU1BBTj48L1NQQU4+PEJSPjxCUj5SZWdhcmRzLDxCUj48QlI+eGlu
ZzxCUj48QlI+PEJSPg0KPEJMT0NLUVVPVEUgY2l0ZT1taWQ6MDg4MDAxY2MwYTgzJGE2NWVkYzkw
JGYzMWM5NWIwJEBjb20gdHlwZT0iY2l0ZSI+PFBSRSB3cmFwPSIiPi1kDQoNCg0KX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkJlaGF2ZSBtYWlsaW5nIGxp
c3QNCjxBIGNsYXNzPW1vei10eHQtbGluay1hYmJyZXZpYXRlZCBocmVmPSJtYWlsdG86QmVoYXZl
QGlldGYub3JnIj5CZWhhdmVAaWV0Zi5vcmc8L0E+DQo8QSBjbGFzcz1tb3otdHh0LWxpbmstZnJl
ZXRleHQgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9iZWhhdmUi
Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYmVoYXZlPC9BPg0KDQoNCjwv
UFJFPjwvQkxPQ0tRVU9URT48QlI+PC9CT0RZPjwvSFRNTD4NCg==

--_000_94C682931C08B048B7A8645303FDC9F33E4DF86CBEPUEXCB1Bnante_--

From ssenthil@cisco.com  Mon May 16 19:47: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 1E76CE0713 for ; Mon, 16 May 2011 19:47:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.202
X-Spam-Level: 
X-Spam-Status: No, score=-9.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 jxI1iSxOVJog for ; Mon, 16 May 2011 19:46:59 -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 85F07E0711 for ; Mon, 16 May 2011 19:46:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ssenthil@cisco.com; l=1497; q=dns/txt; s=iport; t=1305600419; x=1306810019; h=date:subject:from:to:message-id:mime-version; bh=fyURKFC6wA87pGdebYLcnoULl8hyFjx05DWe7Z7SjsE=; b=F8pAs2JqPMwdDydwHvn9MfW/CMxz1aQNyTUEm1XGvcUr9HlU7Zcj+1aq fRe37BbLNiwtKcyX+z1znarIoEH3SW1Obaut30Bj6SzoMliWkg7SbyODo UHpyJbNneQkHPvSp7pDh6ZahhqHjxWTWbKFM4DkqKKrgdmub5VDrZRAi7 I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AlQcAIzg0U2rRDoJ/2dsb2JhbACCZZUmhjEBHhyGNWt3p2uBHZ44hhkEkBGEOIpZ
X-IronPort-AV: E=Sophos;i="4.65,222,1304294400";  d="scan'208,217";a="448928902"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 17 May 2011 02:46:59 +0000
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4H2kxBf014043 for ; Tue, 17 May 2011 02:46:59 GMT
Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 16 May 2011 19:46:59 -0700
Received: from 10.65.87.231 ([10.65.87.231]) by xmb-sjc-236.amer.cisco.com ([128.107.191.121]) with Microsoft Exchange Server HTTP-DAV ;  Tue, 17 May 2011 02:46:59 +0000
User-Agent: Microsoft-Entourage/12.29.0.110113
Date: Mon, 16 May 2011 22:47:13 -0400
From: ssenthil 
To: 
Message-ID: 
Thread-Topic: Adopting NAT logging as WG item
Thread-Index: AcwUPLmFH6AZYocP7E2HljXUYi91hw==
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3388430833_21566325"
X-OriginalArrivalTime: 17 May 2011 02:46:59.0141 (UTC) FILETIME=[B1425750:01CC143C]
Subject: [BEHAVE] Adopting NAT logging as WG item
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, 17 May 2011 02:47:00 -0000

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3388430833_21566325
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

There is a need for CGNs to log connections, as mentioned in
draft-ietf-intarea-server-logging-recommendations. However, we lack a
standard for this logging.
 
I propose the working group consider draft-sivakumar-behave-nat-logging as a
document to fulfill that need.
http://tools.ietf.org/html/draft-sivakumar-behave-nat-logging-01

Thanks
Senthil

--B_3388430833_21566325
Content-type: text/html;
	charset="US-ASCII"
Content-transfer-encoding: quoted-printable



Adopting NAT logging as WG item


There is a need for CGNs to log connections, as mentioned in dr=
aft-ietf-intarea-server-logging-recommendations. However, we lack a standard=
 for this logging.

 

I propose the working group consider draft-sivakumar-behave-nat-logging as =
a document to fulfill that need.

http://tools.ietf.org/html/draft-sivakumar-behave-n=
at-logging-01



Thanks

Senthil




--B_3388430833_21566325--


From tena@huawei.com  Mon May 16 22:27: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 03594E06B9 for ; Mon, 16 May 2011 22:27:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.598
X-Spam-Level: 
X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PVcwWNtNKRtJ for ; Mon, 16 May 2011 22:27:21 -0700 (PDT)
Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by ietfa.amsl.com (Postfix) with ESMTP id 77B9FE069D for ; Mon, 16 May 2011 22:27:21 -0700 (PDT)
Received: from huawei.com (usaml01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLB007RQR5K8D@usaga01-in.huawei.com> for behave@ietf.org; Tue, 17 May 2011 00:27:20 -0500 (CDT)
Received: from TingZousc1 (c-24-7-50-101.hsd1.ca.comcast.net [24.7.50.101]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug  8 2006)) with ESMTPA id <0LLB00HSPR5IWY@usaga01-in.huawei.com> for behave@ietf.org; Tue, 17 May 2011 00:27:20 -0500 (CDT)
Date: Mon, 16 May 2011 22:27:18 -0700
From: Tina Tsou 
In-reply-to: 
To: 'ssenthil' , behave@ietf.org
Message-id: <00a201cc1453$17936b00$46ba4100$@com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-type: multipart/alternative; boundary="Boundary_(ID_0bWCaniKOHp6PqRp2iZzTA)"
Content-language: en-us
Thread-index: AcwUPLmFH6AZYocP7E2HljXUYi91hwAFheYw
References: 
Subject: Re: [BEHAVE] Adopting NAT logging as WG item
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, 17 May 2011 05:27:23 -0000

This is a multi-part message in MIME format.

--Boundary_(ID_0bWCaniKOHp6PqRp2iZzTA)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

Senthil,
Do you think this should be considered as a package?
https://datatracker.ietf.org/doc/draft-tsou-behave-natx4-log-reduction/
 
 
We keep our promises with one another - no matter what!
 
Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html
 
From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of
ssenthil
Sent: Monday, May 16, 2011 7:47 PM
To: behave@ietf.org
Subject: [BEHAVE] Adopting NAT logging as WG item
 
There is a need for CGNs to log connections, as mentioned in
draft-ietf-intarea-server-logging-recommendations. However, we lack a
standard for this logging.
 
I propose the working group consider draft-sivakumar-behave-nat-logging as a
document to fulfill that need.
http://tools.ietf.org/html/draft-sivakumar-behave-nat-logging-01

Thanks
Senthil 

--Boundary_(ID_0bWCaniKOHp6PqRp2iZzTA)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: quoted-printable

Adopting NAT logging =
as WG item
Senthil,
Do you think this should be =
considered as a package?
https://datatracker.ietf.org/doc/draft-tsou-behave-natx4-log-redu=
ction/
 
 
We keep our =
promises with one another – no matter =
what!
 
Best =
Regards,
Tina =
TSOU
http://tinatsou.weebly.com/contact=
.html
 
From: behave-bounces@ietf.org =
[mailto:behave-bounces@ietf.org] On Behalf Of =
ssenthil
Sent: Monday, May 16, 2011 7:47 PM
To: =
behave@ietf.org
Subject: [BEHAVE] Adopting NAT logging as WG =
item
 
There is a need for CGNs to log connections, as =
mentioned in draft-ietf-intarea-server-logging-recommendations. However, =
we lack a standard for this logging.
 
I propose the working =
group consider draft-sivakumar-behave-nat-logging as a document to =
fulfill that need.
http://tools.ietf.org/html/draft-sivakumar-behave-nat-logging-01
=

Thanks
Senthil =

=

--Boundary_(ID_0bWCaniKOHp6PqRp2iZzTA)--

From rpenno@juniper.net  Tue May 17 05:16: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 6DCD5E0769 for ; Tue, 17 May 2011 05:16:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id daMY6S+ObLkU for ; Tue, 17 May 2011 05:16:25 -0700 (PDT)
Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id C850DE075E for ; Tue, 17 May 2011 05:16:24 -0700 (PDT)
Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKTdJnGOizSWTrE25QF6WTd545syxCOxkN@postini.com; Tue, 17 May 2011 05:16:25 PDT
Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 17 May 2011 05:14:27 -0700
Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 17 May 2011 08:14:26 -0400
From: Reinaldo Penno 
To: ssenthil , "behave@ietf.org" 
Date: Tue, 17 May 2011 08:14:24 -0400
Thread-Topic: [BEHAVE] Adopting NAT logging as WG item
Thread-Index: AcwUPLmFH6AZYocP7E2HljXUYi91hwATzwNa
Message-ID: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-Entourage/13.8.0.101117
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [BEHAVE] Adopting NAT logging as WG item
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, 17 May 2011 12:16:26 -0000

Hello Senthil,

I'm familiar with your doc but If the WG would like to standardize logging
we should iron out the information model and then each party is free to map
that to the protocol of choice (IPfix, Binary Log, Raw CSV, etc). Something
like 'CGN Logging Information Model'.

Therefore I would prefer a document that specifies which information is
needed in the case of address sharing and how it should be represented:
timestamp (open-close), private ip, public IP, public port, etc.

Other considerations are needed, e.g., in case of DS-Lite softwire ID would
be needed, and with overlapping IPs the VRF (or equivalent) should be
present, etc

Thanks,

Reinaldo

On 5/16/11 7:47 PM, "ssenthil"  wrote:

> There is a need for CGNs to log connections, as mentioned in
> draft-ietf-intarea-server-logging-recommendations. However, we lack a sta=
ndard
> for this logging.
>=20
> I propose the working group consider draft-sivakumar-behave-nat-logging a=
s a
> document to fulfill that need.
> http://tools.ietf.org/html/draft-sivakumar-behave-nat-logging-01
>=20
> Thanks
> Senthil


From ietfdbh@comcast.net  Tue May 17 09:26: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 CF3DBE0748 for ; Tue, 17 May 2011 09:26:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.462
X-Spam-Level: 
X-Spam-Status: No, score=-102.462 tagged_above=-999 required=5 tests=[AWL=0.137, 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 IqAlLs1IQ3BN for ; Tue, 17 May 2011 09:26:29 -0700 (PDT)
Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by ietfa.amsl.com (Postfix) with ESMTP id 56CA9E0746 for ; Tue, 17 May 2011 09:26:29 -0700 (PDT)
Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta14.westchester.pa.mail.comcast.net with comcast id kg8a1g0081ap0As5EgSV1F; Tue, 17 May 2011 16:26:29 +0000
Received: from davidPC ([67.189.235.106]) by omta22.westchester.pa.mail.comcast.net with comcast id kgSV1g00K2JQnJT3igSVvL; Tue, 17 May 2011 16:26:29 +0000
From: "David Harrington" 
To: "'Iljitsch van Beijnum'" , 
References: <20110509163003.30973.76585.idtracker@ietfa.amsl.com> 
In-Reply-To: 
Date: Tue, 17 May 2011 12:26:13 -0400
Message-ID: 
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: AcwObrFCeZn4C/haTSCoQWIVFGw1iQGQF2LA
Subject: Re: [BEHAVE] I-D ACTION:draft-ietf-behave-ftp64-09.txt
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 May 2011 16:26:31 -0000

Hi,

AD is being slow. 
Hope to finish AD review today.

dbh 

> -----Original Message-----
> From: behave-bounces@ietf.org 
> [mailto:behave-bounces@ietf.org] On Behalf Of Iljitsch van Beijnum
> Sent: Monday, May 09, 2011 1:15 PM
> To: behave@ietf.org WG
> Subject: Re: [BEHAVE] I-D ACTION:draft-ietf-behave-ftp64-09.txt
> 
> On 9 mei 2011, at 18:30, Internet-Drafts@ietf.org wrote:
> 
> > A new Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> > This draft is a work item of the Behavior Engineering for 
> Hindrance Avoidance Working Group of the IETF.
> 
> >    Title         : An FTP ALG for IPv6-to-IPv4 translation
> >    Author(s)     : I. van Beijnum
> >    Filename      : draft-ietf-behave-ftp64-09.txt
> >    Pages         : 16
> >    Date          : 2011-05-02
> 
> In case anyone's wondering: there are no changes to the text, 
> just pointers to the new RFCs. (And the draft was published a 
> week ago, why the delay?)
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave
> 


From ietfdbh@comcast.net  Tue May 17 11:04: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 3E283E0720 for ; Tue, 17 May 2011 11:04:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.658
X-Spam-Level: 
X-Spam-Status: No, score=-101.658 tagged_above=-999 required=5 tests=[AWL=-0.689, 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 ZiqkQYR7akCs for ; Tue, 17 May 2011 11:04:01 -0700 (PDT)
Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5A9E06B0 for ; Tue, 17 May 2011 11:04:01 -0700 (PDT)
Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta04.westchester.pa.mail.comcast.net with comcast id khw51g00B1vXlb854i40YW; Tue, 17 May 2011 18:04:00 +0000
Received: from davidPC ([67.189.235.106]) by omta17.westchester.pa.mail.comcast.net with comcast id ki3z1g0062JQnJT3di40ja; Tue, 17 May 2011 18:04:00 +0000
From: "David Harrington" 
To: , , 
Date: Tue, 17 May 2011 14:03:44 -0400
Message-ID: <3A4AC3EA076C4B6389C5E6F31CD9A16E@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: AcwUvMMFrYSWNSWpQUip9+I5PSK5+g==
Subject: [BEHAVE] AD review: draft-ietf-behave-ftp64-09
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, 17 May 2011 18:04:02 -0000

Hi,

I reviewed draft-ietf-behave-ftp64 and have a few questions.
Overall I think the document looks to be in good shape.
I spotted a few things that might cause IESG approval to be delayed,
and had a couple questions because I am not an expert in the content.
Some text modifications might make things clearer.

1) should security considerations discuss trust between client-alg and
alg-
server? I assume TLS cannot be used end-to-end for FTP, but must be
hop-to-hop
client-to-alg, and alg-to-server. Assuming different credentials
apply, the
secuirty association must be established between the client and the
alg, not
client-server, and the security association  must be established
between the alg
and server, not client-server. I would also assume that how this is
accomplished
depends on whether active or passive mode is being used to establish
connections.
The text as written might already already say that only passive
mode is used in the presence of TLS protection, but I'm not sure that
is what
the text says. This might be made clearer.

2) section 4 "As such, an ALG used with a stateful translator MUST
support EPSV
and MAY support EPRT. However, an ALG used with a stateless translator
SHOULD
also support EPRT. " Is there a requirement regarding stateless and
EPSV?

3) in section 9, "Implementations SHOULD NOT try to detect the
situation where
both PASV and PORT commands are issued prior to a command that
initiates a
transfer, but rather, apply the same translation they would have if
there had
not been a PASV command prior to a PORT command or a PORT command
prior to a
PASV command. " I find this a bit ambiguous. Is it expected that the
translation
they would have done be based on having received only the second
command (as if
the first had not been received), or based on not having received
either?

4) should the NOOP in section 12 be reflected in the ABNF algs-command
?

5) draft-liu-ftp64-extensions should be updated to
draft-ietf-ftpext2-ftp64
during subsequent processing.

6) The normative reference to ftpext2 work could cause this document
to be held
up in processing. is there a way to eliminate this reference? Can an
implementation "support EPSV successfully" without this ftpext2
extension? The
text isn't clear that "successfully" means requiring support for an
IPv4-IPv6
translation environment; that is only implied by the choice of
reference [2428]
vs [ftpext2]. 

Thanks,
David Harrington
Director, IETF Transport Area
ietfdbh@comcast.net (preferred for ietf)
dbharrington@huaweisymantec.com
+1 603 828 1401 (cell)


From ssenthil@cisco.com  Tue May 17 22:11:44 2011
Return-Path: 
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1266BE0697 for ; Tue, 17 May 2011 22:11:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.833
X-Spam-Level: 
X-Spam-Status: No, score=-7.833 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JW1nTTcqIUGy for ; Tue, 17 May 2011 22:11:42 -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 6A14DE0681 for ; Tue, 17 May 2011 22:11:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ssenthil@cisco.com; l=4278; q=dns/txt; s=iport; t=1305695502; x=1306905102; h=date:subject:from:to:message-id:in-reply-to:mime-version; bh=/CwivBLF0FpdBymxUzP4UXpDc0om8H0apVj/QyljbOg=; b=M0pluKkWfq0eHYsTv+5JX3zCvu8R+Y4e//CRWPDt6WNG9YxUZtWw4Ctn JQPPc0IqaBT89n9esPGXTv9aQqiQ7CJRmU5zFEIdlvZBNq2NHJl62Dx67 04AEL/F3miCPyJJVWKerYod9AfUe8/xMVXotD+Zv3hDwLK8YjKuBUFM+Z E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiEBAAxU002rRDoI/2dsb2JhbACCZZRmhnEBhnFnAneIcKAongyGGQSQEYQ4ilk
X-IronPort-AV: E=Sophos;i="4.65,229,1304294400";  d="scan'208,217";a="449766328"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-1.cisco.com with ESMTP; 18 May 2011 05:11:41 +0000
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4I5BfYQ025515; Wed, 18 May 2011 05:11:41 GMT
Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 17 May 2011 22:11:41 -0700
Received: from 72.163.188.236 ([72.163.188.236]) by xmb-sjc-236.amer.cisco.com ([128.107.191.121]) with Microsoft Exchange Server HTTP-DAV ;  Wed, 18 May 2011 05:11:41 +0000
User-Agent: Microsoft-Entourage/12.29.0.110113
Date: Wed, 18 May 2011 01:11:56 -0400
From: ssenthil 
To: Tina Tsou , 
Message-ID: 
Thread-Topic: [BEHAVE] Adopting NAT logging as WG item
Thread-Index: AcwUPLmFH6AZYocP7E2HljXUYi91hwAFheYwADHSkrY=
In-Reply-To: <00a201cc1453$17936b00$46ba4100$@com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3388525917_25103752"
X-OriginalArrivalTime: 18 May 2011 05:11:41.0544 (UTC) FILETIME=[12C9A680:01CC151A]
Subject: Re: [BEHAVE] Adopting NAT logging as WG item
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, 18 May 2011 05:11:44 -0000

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3388525917_25103752
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

I see reduction of logs as an optimization and there are many ways to
optimize, my draft considers that out of scope.
But if the WG consensus is to have it integrated I will be fine with it.

Senthil


On 5/17/11 1:27 AM, "Tina Tsou"  wrote:

> Senthil,
> Do you think this should be considered as a package?
> https://datatracker.ietf.org/doc/draft-tsou-behave-natx4-log-reduction/
> =20
>=20
> =20
> We keep our promises with one another =AD no matter what!
> =20
> Best Regards,
> Tina TSOU
> http://tinatsou.weebly.com/contact.html
> =20
>=20
> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf =
Of
> ssenthil
> Sent: Monday, May 16, 2011 7:47 PM
> To: behave@ietf.org
> Subject: [BEHAVE] Adopting NAT logging as WG item
> =20
> There is a need for CGNs to log connections, as mentioned in
> draft-ietf-intarea-server-logging-recommendations. However, we lack a sta=
ndard
> for this logging.
> =20
> I propose the working group consider draft-sivakumar-behave-nat-logging a=
s a
> document to fulfill that need.
> http://tools.ietf.org/html/draft-sivakumar-behave-nat-logging-01
>=20
> Thanks
> Senthil=20
>=20


--B_3388525917_25103752
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable



Re: [BEHAVE] Adopting NAT logging as WG item


I see reduction of logs as an optimization and there are many ways to opti=
mize, my draft considers that out of scope.

But if the WG consensus is to have it integrated I will be fine with it.


Senthil





On 5/17/11 1:27 AM, "Tina Tsou" <ten=
a@huawei.com> wrote:




<=
SPAN STYLE=3D'font-size:11pt'>Senthil,

Do you think this should be considered as a package?

https://datatracker.ietf.org/doc/draft-tsou-behave-natx4-log-reductio=
n/

 



 

We keep our promises with one another – no matter what!

 

Best Regards,

Tina TSOU

http://tinatsou.weebly.co=
m/contact.html

 



From: behave-bounces@ietf.org [mailt=
o:behave-bounces@ietf.org] On Behalf Of ssenthil

Sent: Monday, May 16, 2011 7:47 PM

To: behave@ietf.org

Subject: [BEHAVE] Adopting NAT logging as WG item

 

There is a need for CGNs to log connections, as m=
entioned in draft-ietf-intarea-server-logging-recommendations. However, we l=
ack a standard for this logging.

 

I propose the working group consider draft-sivakumar-behave-nat-logging as =
a document to fulfill that need.

http://tools.ietf.org/html/draft-sivakumar-behave-n=
at-logging-01



Thanks

Senthil 









--B_3388525917_25103752--


From ssenthil@cisco.com  Tue May 17 22:17:21 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 21753E06B2 for ; Tue, 17 May 2011 22:17:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.183
X-Spam-Level: 
X-Spam-Status: No, score=-8.183 tagged_above=-999 required=5 tests=[AWL=0.349,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6hnw8+SPjiD for ; Tue, 17 May 2011 22:17:20 -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 8D6EFE0697 for ; Tue, 17 May 2011 22:17:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ssenthil@cisco.com; l=1570; q=dns/txt; s=iport; t=1305695840; x=1306905440; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=6Jc/jw8IBexrjwueOOCqjpTxJzJ5U0Sn7LJOviNE/hM=; b=KwoBrAOlFu3wWBF3Uqe/k2si1HVnz0+CY6GNMYGSTvPvmt0IDszXbz8H k/qg3/47fyHyZnv1caBP/mueWvbQLmicspZVz1hH22WSROuCCoNpl3AS+ mbynNEBkv9bXNbsFoJ8LDGIFeeNd1uuqPBAeZcwbFe2QQTI/vO28RPu6O o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AnEFAEJV002rRDoI/2dsb2JhbACmFQJ3iHCgNZ4KhhkEkBGEOIpZ
X-IronPort-AV: E=Sophos;i="4.65,229,1304294400"; d="scan'208";a="318116311"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 18 May 2011 05:17:19 +0000
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4I5HJc9028863; Wed, 18 May 2011 05:17:19 GMT
Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 17 May 2011 22:16:28 -0700
Received: from 72.163.188.236 ([72.163.188.236]) by xmb-sjc-236.amer.cisco.com ([128.107.191.121]) with Microsoft Exchange Server HTTP-DAV ;  Wed, 18 May 2011 05:16:27 +0000
User-Agent: Microsoft-Entourage/12.29.0.110113
Date: Wed, 18 May 2011 01:16:43 -0400
From: ssenthil 
To: Reinaldo Penno , "behave@ietf.org" 
Message-ID: 
Thread-Topic: [BEHAVE] Adopting NAT logging as WG item
Thread-Index: AcwUPLmFH6AZYocP7E2HljXUYi91hwATzwNaACO0OdI=
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 18 May 2011 05:16:28.0212 (UTC) FILETIME=[BDA7B740:01CC151A]
Subject: Re: [BEHAVE] Adopting NAT logging as WG item
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, 18 May 2011 05:17:21 -0000

On 5/17/11 8:14 AM, "Reinaldo Penno"  wrote:

> Hello Senthil,
> 
> I'm familiar with your doc but If the WG would like to standardize logging
> we should iron out the information model and then each party is free to map
> that to the protocol of choice (IPfix, Binary Log, Raw CSV, etc). Something
> like 'CGN Logging Information Model'.
> 
> Therefore I would prefer a document that specifies which information is
> needed in the case of address sharing and how it should be represented:
> timestamp (open-close), private ip, public IP, public port, etc.
> 
Maybe I am confused, the logging draft in fact is attempting to specify what
information elements are to be logged. It leaves it up to the implementation
on choosing the transport (ipfix, netflow etc).

> Other considerations are needed, e.g., in case of DS-Lite softwire ID would
> be needed, and with overlapping IPs the VRF (or equivalent) should be
> present, etc

All of this are specified in the draft (VRF ID or VLAN ID or subscriber ID).

Thanks
Senthil
> 
> Thanks,
> 
> Reinaldo
> 
> On 5/16/11 7:47 PM, "ssenthil"  wrote:
> 
>> There is a need for CGNs to log connections, as mentioned in
>> draft-ietf-intarea-server-logging-recommendations. However, we lack a
>> standard
>> for this logging.
>> 
>> I propose the working group consider draft-sivakumar-behave-nat-logging as a
>> document to fulfill that need.
>> http://tools.ietf.org/html/draft-sivakumar-behave-nat-logging-01
>> 
>> Thanks
>> Senthil
> 


From rpenno@juniper.net  Wed May 18 01:22:44 2011
Return-Path: 
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE48E07DD for ; Wed, 18 May 2011 01:22:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0bOyQwWjbzR for ; Wed, 18 May 2011 01:22:43 -0700 (PDT)
Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id EC586E07DC for ; Wed, 18 May 2011 01:22:41 -0700 (PDT)
Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKTdOB0VEYHRb+oKIChfGP1u3wnMaIAVHt@postini.com; Wed, 18 May 2011 01:22:42 PDT
Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 18 May 2011 01:19:44 -0700
Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Wed, 18 May 2011 04:19:43 -0400
From: Reinaldo Penno 
To: ssenthil , "behave@ietf.org" 
Date: Wed, 18 May 2011 04:19:42 -0400
Thread-Topic: [BEHAVE] Adopting NAT logging as WG item
Thread-Index: AcwUPLmFH6AZYocP7E2HljXUYi91hwATzwNaACO0OdIABmQA3g==
Message-ID: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-Entourage/13.8.0.101117
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [BEHAVE] Adopting NAT logging as WG item
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, 18 May 2011 08:22:44 -0000

Senthil,

On 5/17/11 10:16 PM, "ssenthil"  wrote:

> Maybe I am confused, the logging draft in fact is attempting to specify w=
hat
> information elements are to be logged. It leaves it up to the implementat=
ion
> on choosing the transport (ipfix, netflow etc).

"   This document assumes that the NAT device will use some existing
   framework like IPFIX, Netflow version 9 etc to send the log events to
   the collector.
"

Also, The draft also posit that the format is binary

"   This document assumes that the NAT device will send the events in a
   binary format to an off-box collector to be able to scale to carrier
   grade NAT requirements but the formats (binary or ASCII) itself is
   beyond the scope of this document.
"

And finally reuses Ipfix information IDs.

I'm looking for a draft scrubbed of these protocol specific language which
defines the information model.

Thanks,

Reinaldo


From ssenthil@cisco.com  Wed May 18 02:26:57 2011
Return-Path: 
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD611E0736 for ; Wed, 18 May 2011 02:26:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.299
X-Spam-Level: 
X-Spam-Status: No, score=-8.299 tagged_above=-999 required=5 tests=[AWL=0.233,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NmFaQnqXlzq7 for ; Wed, 18 May 2011 02:26:57 -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 2F588E06E9 for ; Wed, 18 May 2011 02:26:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ssenthil@cisco.com; l=1812; q=dns/txt; s=iport; t=1305710817; x=1306920417; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=OyqpA4V46WuuktuWDCpEBRlNvJzfEIzHpWWx6Z/QjXE=; b=X0D45Uo86YtpnIwf2BbkEs4/icZQfplJ53LmHUjDM7GAggH9OQzzJ91F Pb/t/cBA8PuwmAbiCCg5GHHdaJEdQgUsmbksZ+hkhbmaJaMVZJ9zxKotx zhxPO8RHkwzhnneC/KgTtgUTZY1iTTcVCk3P7YmleEXxJAavh6uCo1Qxv U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AsAFAEGQ002rRDoJ/2dsb2JhbACJIpxzAneIcKENnguGGQSQEYQ4ilk
X-IronPort-AV: E=Sophos;i="4.65,230,1304294400"; d="scan'208";a="699332969"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-6.cisco.com with ESMTP; 18 May 2011 09:26:56 +0000
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4I9Qus1024181; Wed, 18 May 2011 09:26:56 GMT
Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 18 May 2011 02:26:56 -0700
Received: from 72.163.188.236 ([72.163.188.236]) by xmb-sjc-236.amer.cisco.com ([128.107.191.121]) with Microsoft Exchange Server HTTP-DAV ;  Wed, 18 May 2011 09:26:54 +0000
User-Agent: Microsoft-Entourage/12.29.0.110113
Date: Wed, 18 May 2011 05:26:55 -0400
From: ssenthil 
To: Reinaldo Penno , "behave@ietf.org" 
Message-ID: 
Thread-Topic: [BEHAVE] Adopting NAT logging as WG item
Thread-Index: AcwUPLmFH6AZYocP7E2HljXUYi91hwATzwNaACO0OdIABmQA3gACWPcT
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 18 May 2011 09:26:56.0536 (UTC) FILETIME=[BB3BF980:01CC153D]
Subject: Re: [BEHAVE] Adopting NAT logging as WG item
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, 18 May 2011 09:26:58 -0000

On 5/18/11 4:19 AM, "Reinaldo Penno"  wrote:

> Senthil,
> 
> On 5/17/11 10:16 PM, "ssenthil"  wrote:
> 
>> Maybe I am confused, the logging draft in fact is attempting to specify what
>> information elements are to be logged. It leaves it up to the implementation
>> on choosing the transport (ipfix, netflow etc).
> 
> "   This document assumes that the NAT device will use some existing
>    framework like IPFIX, Netflow version 9 etc to send the log events to
>    the collector.
> "
Right, and the next sentence is
"  But it is beyond the scope of the document to define
   the framework to be used for logging.  However, the framework should
   support specifying a template that the NAT device will use to send
   its events. "

The point of the above paragraph is that this document does not attempt to
define the framework and the implementation is free to choose its framework.

> 
> Also, The draft also posit that the format is binary
> 
> "   This document assumes that the NAT device will send the events in a
>    binary format to an off-box collector to be able to scale to carrier
>    grade NAT requirements but the formats (binary or ASCII) itself is
>    beyond the scope of this document.
> "
> 
[Senthil] You cant use ASCII to log events as it wouldn't scale, so I
assumed that you have binary. Is that restrictive? What other formats do you
think that may be the choices here?

> And finally reuses Ipfix information IDs.
> 

[Senthil] Ah, this maybe the source of confusion. If I remove the IPFIX IDs
would that help your concerns?

Thanks
Senthil

> I'm looking for a draft scrubbed of these protocol specific language which
> defines the information model.
> 
> Thanks,
> 
> Reinaldo
> 


From rpenno@juniper.net  Wed May 18 03:07:29 2011
Return-Path: 
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 435D8E0671 for ; Wed, 18 May 2011 03:07:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOL13MjyzPUf for ; Wed, 18 May 2011 03:07:28 -0700 (PDT)
Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id AE0C9E066C for ; Wed, 18 May 2011 03:07:27 -0700 (PDT)
Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKTdOaXjhMboD+y0+HBtGg5HpO1jL8MBXu@postini.com; Wed, 18 May 2011 03:07:28 PDT
Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 18 May 2011 03:05:20 -0700
Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Wed, 18 May 2011 06:05:19 -0400
From: Reinaldo Penno 
To: ssenthil , "behave@ietf.org" 
Date: Wed, 18 May 2011 06:05:16 -0400
Thread-Topic: [BEHAVE] Adopting NAT logging as WG item
Thread-Index: AcwUPLmFH6AZYocP7E2HljXUYi91hwATzwNaACO0OdIABmQA3gACWPcTAAFW4GU=
Message-ID: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-Entourage/13.8.0.101117
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [BEHAVE] Adopting NAT logging as WG item
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, 18 May 2011 10:07:29 -0000

On 5/18/11 2:26 AM, "ssenthil"  wrote:

>=20
>=20
>=20
> On 5/18/11 4:19 AM, "Reinaldo Penno"  wrote:
>=20
>> Senthil,
>>=20
>> On 5/17/11 10:16 PM, "ssenthil"  wrote:
>>=20
>>> Maybe I am confused, the logging draft in fact is attempting to specify=
 what
>>> information elements are to be logged. It leaves it up to the implement=
ation
>>> on choosing the transport (ipfix, netflow etc).
>>=20
>> "   This document assumes that the NAT device will use some existing
>>    framework like IPFIX, Netflow version 9 etc to send the log events to
>>    the collector.
>> "
> Right, and the next sentence is
> "  But it is beyond the scope of the document to define
>    the framework to be used for logging.  However, the framework should
>    support specifying a template that the NAT device will use to send
>    its events. "

'Template' is IPfix terminology. Logging format is outside the scope of
logging document as you propose.

>=20
> The point of the above paragraph is that this document does not attempt t=
o
> define the framework and the implementation is free to choose its framewo=
rk.
>=20
>>=20
>> Also, The draft also posit that the format is binary
>>=20
>> "   This document assumes that the NAT device will send the events in a
>>    binary format to an off-box collector to be able to scale to carrier
>>    grade NAT requirements but the formats (binary or ASCII) itself is
>>    beyond the scope of this document.
>> "
>>=20
> [Senthil] You cant use ASCII to log events as it wouldn't scale, so I
> assumed that you have binary. Is that restrictive? What other formats do =
you
> think that may be the choices here?

That depends on the implementation. Some scale others do not. But Scale is
out of the scope of this document as I understand.

A CGN box is one that has to deal with address sharing, whether for 10 or 1=
M
subscribers the logging functionality problems are the same.

Therefore let's focus on the information model.

>=20
>> And finally reuses Ipfix information IDs.
>>=20
>=20
> [Senthil] Ah, this maybe the source of confusion. If I remove the IPFIX I=
Ds
> would that help your concerns?
>=20
> Thanks
> Senthil
>=20
>> I'm looking for a draft scrubbed of these protocol specific language whi=
ch
>> defines the information model.
>>=20
>> Thanks,
>>=20
>> Reinaldo
>>=20
>=20


From linfeng.john.zheng@gmail.com  Tue May 17 20:57:24 2011
Return-Path: 
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2BFAE07D3 for ; Tue, 17 May 2011 20:57:24 -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 Qc9vntxzAhRt for ; Tue, 17 May 2011 20:57:20 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 15A17E07CB for ; Tue, 17 May 2011 20:57:20 -0700 (PDT)
Received: by iwn39 with SMTP id 39so1229355iwn.31 for ; Tue, 17 May 2011 20:57:19 -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=beW09O6VslgSZqO1+e2lJ/NfgtUpwwmaHf5spF6h7mo=; b=cptRD5TSyvNTRRNCz5R8IG7NVurxiVsBMXMfi4Ssp7kLVtaO1BNXL6FuYuim7xGJDJ rewqPhx5b9DK+1Cx5vydxI2K9BTjPLEbzD5RMo5bubg5Y8L9R5QX2GcIDA9DzdxYreEK lHEtWVweBRGsKj4bRyKVnINUwMtohbT7G7Mqo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Wc9VExS9gaiLbDp04UYBSwfKV86xsfZVLXDaYSUIfGHYavcQLucNQDAzPkA6Fq/2tN lQ7ZmMBO5Z8Sy/odJWHEFPLav8tXDRlT7fbG+o0DOZSjUuPnlDABJ4KArqiGI/a6oWna of1vTcKFeoyCN8k5WjUIyu8QwanR4Nh0YwF1A=
MIME-Version: 1.0
Received: by 10.231.177.69 with SMTP id bh5mr1020466ibb.62.1305691039519; Tue, 17 May 2011 20:57:19 -0700 (PDT)
Received: by 10.231.174.132 with HTTP; Tue, 17 May 2011 20:57:19 -0700 (PDT)
Date: Wed, 18 May 2011 11:57:19 +0800
Message-ID: 
From: Linfeng Zheng 
To: behave@ietf.org
Content-Type: multipart/alternative; boundary=00504501740898d43804a384e237
Subject: Re: [BEHAVE] I-D ACTION:draft-ietf-behave-ftp64-09.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, 18 May 2011 21:19:28 -0000

--00504501740898d43804a384e237
Content-Type: text/plain; charset=ISO-8859-1

   >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.

if it possible to get a more recent one?

bests, Linfeng CCIE#8670

--00504501740898d43804a384e237
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


=A0=A0 >A survey done in April of 2009 of 25 randomly picked and/or=
 well-
=A0=A0 >known FTP sites reachable over IPv4 showed that only 1=
2 of them
=A0=A0 >supported EPSV over IPv4.=A0 


=A0


if it possible to get a more recent one?


=A0


bests, Linfeng CCIE#8670


--00504501740898d43804a384e237--

From cb.list6@gmail.com  Wed May 18 15:18:01 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 01722E0760 for ; Wed, 18 May 2011 15:18:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.384
X-Spam-Level: 
X-Spam-Status: No, score=-3.384 tagged_above=-999 required=5 tests=[AWL=0.215,  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 6BlqvNauTnMw for ; Wed, 18 May 2011 15:18:00 -0700 (PDT)
Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 33494E070C for ; Wed, 18 May 2011 15:18:00 -0700 (PDT)
Received: by ewy19 with SMTP id 19so809166ewy.31 for ; Wed, 18 May 2011 15:17:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Xa9v2J+MPBzpmACKGR/Mv0B3oNN5TxO7irM2qIMCjwk=; b=rGYu0GK6lr9U0FAZBNWWsWXxBsSWK1HfAMfRLkAlRMy/UEBwIgLq70cGPoiLWFNv56 bz/qNyXDzpmj4iTAjEfKpsVakjRz6uI3Mg3spLj1XiS6N2oMJqKj883KHvyzFU+1ukCZ CYXCU5q+LWY3UJfJzvQGBHrIJ5M5L/Bv6geVM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Y3B08a87T+9+jeGKQu9KGJ9k5ipiPtFG/A4WAzWnO5crxCcQ1RtqtfpChU+lok4Ekl gWJVHdMf/5cuMvOyMNhVLTll9czcBy1GcI02qrmCloQwFitYPvfzvq2omK+Wvk95P0ne UBaxl/v+eQ/OvpcyF/OMR3H7KRpEfBQ5WWCjE=
MIME-Version: 1.0
Received: by 10.14.43.218 with SMTP id l66mr839409eeb.188.1305757079243; Wed, 18 May 2011 15:17:59 -0700 (PDT)
Received: by 10.14.47.67 with HTTP; Wed, 18 May 2011 15:17:59 -0700 (PDT)
In-Reply-To: 
References: 
Date: Wed, 18 May 2011 15:17:59 -0700
Message-ID: 
From: Cameron Byrne 
To: ssenthil 
Content-Type: text/plain; charset=ISO-8859-1
Cc: behave@ietf.org
Subject: Re: [BEHAVE] Adopting NAT logging as WG item
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, 18 May 2011 22:18:01 -0000

Per 3GPP specification, which is also outlined in
draft-ietf-v6ops-3gpp-eps-01, each subscriber of a 3GPP PDP or EPS
bearer is given a /64 and the user equipment can determine the final
64 host bits (there is no variation from this structure in 3GPP).

I am sure this will be the same case in other access network
architectures, including the use of privacy extensions ... meaning...
the first 64 bits is a unique user and the last 64 bits do not have
any useful meaning in the context of logging, billing, ...  This may
even be the case for DHCP-PD /56s or whatever is given to DSL or Cable
subscribers.

The network operator that is running the NAT may not care about the
final 64 host / subscriber bits and it may be beneficial for multiple
purposes (billing, DPI, business intelligence ...) that the subscriber
/ customer be viewed and treated on only the first 64 bits.  This data
reduction (truncating the last 64 bits) may be beneficial on the
initial log creation and therefore it may be beneficial to add a 64
bit version of "sourceIPv6Address" field

Cameron

From dwing@cisco.com  Wed May 18 17:50:09 2011
Return-Path: 
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE6EE0674 for ; Wed, 18 May 2011 17:50:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.413
X-Spam-Level: 
X-Spam-Status: No, score=-110.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 lLiTZWZf0GpF for ; Wed, 18 May 2011 17:50:07 -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 9C42AE06C2 for ; Wed, 18 May 2011 17:50:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1933; q=dns/txt; s=iport; t=1305766207; x=1306975807; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=SJ1SWf2Bt7iknDbcViNYxCrePhP5CDY8kOaXoi+BirE=; b=eVbg/hSIsextU7xryUZ5XZqW3RlMY5tftuGxuOyYfIrTh4uaCZNmVxOY N4X9OrP7TqWMZLfpg47L0ReASSk3B/L3d9XdtbhZd2i3UarOvhr5pFWD8 k/u9Ny2mHiEgHastVHuRIvgI4EWRcm6qZU5Ur322qQVu85xY4+V9sq/H6 w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EANxo1E2rRDoG/2dsb2JhbACZM4xpd6lhnX2GGQSGUJhW
X-IronPort-AV: E=Sophos;i="4.65,234,1304294400"; d="scan'208";a="450429852"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-1.cisco.com with ESMTP; 19 May 2011 00:50:06 +0000
Received: from dwingWS ([10.32.240.195]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4J0o6j4019515; Thu, 19 May 2011 00:50:06 GMT
From: "Dan Wing" 
To: "'Linfeng Zheng'" , 
References: 
In-Reply-To: 
Date: Wed, 18 May 2011 17:50:06 -0700
Message-ID: <005d01cc15be$b2415f60$16c41e20$@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: AcwVoVslcWqAZh32Q8mf9omRdiuGqQAHBzmQ
Content-Language: en-us
Subject: Re: [BEHAVE] I-D ACTION:draft-ietf-behave-ftp64-09.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, 19 May 2011 00:50:09 -0000

>    >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.
> 
> if it possible to get a more recent one?

The previous test's output, and Perl module changes necessary to
do the test and the perl files to run the test, are at:
  ftp://ftp-eng.cisco.com/dwing/ftp-epsv/

Here are several sample sites that I checked just now.  The times 
indicate how long before a timeout or connection occured (mm:ss),

ftp.kodak.com             PASV: Ok   EPSV: Ok     00:02
ftp.microsoft.com         PASV: Ok   EPSV: Ok     00:00
ftp.novell.com            PASV: Ok   EPSV: Ok     00:01
rtfm.mit.edu              PASV: Ok   EPSV: Ok     00:01
ftp.freebsd.org           PASV: Ok   EPSV: Ok     00:00
ftp.fu-berlin.de          PASV: Ok   EPSV: Ok     00:03
ftp.internic.net          PASV: Ok   EPSV: Ok     00:01
ftp.arin.net              PASV: Ok   EPSV: Ok     00:02
ftp.oreilly.com           PASV: Ok   EPSV: Ok     00:01
ftp.mozilla.org           PASV: Ok   EPSV: Ok     00:00
ftp.dell.com              PASV: Ok   EPSV: Timeout   00:22
ftp.sun.com               PASV: Ok   EPSV: Timeout   00:23
ftp.nortel.com            PASV: Ok   EPSV: Timeout   00:22
ssd.jpl.nasa.gov          PASV: Ok   EPSV: Ok     00:01
ftp.rfc-editor.org        PASV: Ok   EPSV: Ok     00:01
ftp.cdc.gov               PASV: Ok   EPSV: 500 'EPSV': command not 
understood 00:01
ftp.hp.com                PASV: Ok   EPSV: 500 'EPSV': command not 
understood.  00:01
ftp.sony.com              PASV: Ok   EPSV: 500 'EPSV': command not 
understood.  00:02
www.3gpp.org              PASV: Ok   EPSV: 500 'EPSV': command not 
understood  00:03
ftp.estec.esa.nl          PASV: Ok   EPSV: 500 'EPSV': command not 
understood.  00:03
ftpeng.cisco.com          PASV: Ok   EPSV: 500 'EPSV': command not 
understood.  00:01

-d



From internet-drafts@ietf.org  Wed May 18 23:35:21 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 BC072E0779; Wed, 18 May 2011 23:35:21 -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 GcvCO2vuzdd2; Wed, 18 May 2011 23:35:21 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A868E0763; Wed, 18 May 2011 23:35:21 -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.54
Message-ID: <20110519063521.23800.46878.idtracker@ietfa.amsl.com>
Date: Wed, 18 May 2011 23:35:21 -0700
Cc: behave@ietf.org
Subject: [BEHAVE] I-D Action: draft-ietf-behave-64-analysis-03.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, 19 May 2011 06:35:21 -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           : Analysis of Stateful 64 Translation
	Author(s)       : Reinaldo Penno
                          Tarun Saxena
                          Mohamed Boucadair
                          Senthil Sivakumar
	Filename        : draft-ietf-behave-64-analysis-03.txt
	Pages           : 15
	Date            : 2011-05-18

   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 stateful translation mechanisms avoid the problems that
   caused the IETF to deprecate NAT-PT.



A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-behave-64-analysis-03.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-64-analysis-03.txt

From ssenthil@cisco.com  Thu May 19 20:47:15 2011
Return-Path: 
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAAEDE0659 for ; Thu, 19 May 2011 20:47:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.848
X-Spam-Level: 
X-Spam-Status: No, score=-8.848 tagged_above=-999 required=5 tests=[AWL=-0.354, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.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 5rnyOmwst8i9 for ; Thu, 19 May 2011 20:47:14 -0700 (PDT)
Received: from sj-iport-6.cisco.com (unknown [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id B31BCE0651 for ; Thu, 19 May 2011 20:47:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ssenthil@cisco.com; l=2780; q=dns/txt; s=iport; t=1305863234; x=1307072834; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=Ndyg2BfxPxn0DB90qRJ8Vuj/QVRCeZpYO6LKZR3oIrc=; b=B/Z6qcyBK6coZxOox28lCRc5ilp+vg6NpwgLcNNxVFLFDxcDma0TY99T IyLLQqs5jmOQvhw2mASPO1/drWzUTAIRkCmOQNJN+55MCLGDtGiCo0IGl kSJ144ETvs6s+mdgWbXkJw6RGdBepUSWzSyrrT4rPmoFw04YNPWtainIQ g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAJLj1U2rRDoG/2dsb2JhbACmGXeoZp1/hhkEkBGEOIpZ
X-IronPort-AV: E=Sophos;i="4.65,240,1304294400"; d="scan'208";a="700587296"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-6.cisco.com with ESMTP; 20 May 2011 03:47:14 +0000
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4K3lDlv022129; Fri, 20 May 2011 03:47:14 GMT
Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 19 May 2011 20:46:02 -0700
Received: from 10.65.84.60 ([10.65.84.60]) by xmb-sjc-236.amer.cisco.com ([128.107.191.121]) with Microsoft Exchange Server HTTP-DAV ;  Fri, 20 May 2011 03:46:02 +0000
User-Agent: Microsoft-Entourage/12.29.0.110113
Date: Thu, 19 May 2011 23:45:26 -0400
From: ssenthil 
To: Reinaldo Penno , "behave@ietf.org" 
Message-ID: 
Thread-Topic: [BEHAVE] Adopting NAT logging as WG item
Thread-Index: AcwUPLmFH6AZYocP7E2HljXUYi91hwATzwNaACO0OdIABmQA3gACWPcTAAFW4GUAV1E7hA==
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 20 May 2011 03:46:02.0742 (UTC) FILETIME=[70A63160:01CC16A0]
Subject: Re: [BEHAVE] Adopting NAT logging as WG item
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, 20 May 2011 03:47:15 -0000

On 5/18/11 6:05 AM, "Reinaldo Penno"  wrote:

> 
> 
> 
> On 5/18/11 2:26 AM, "ssenthil"  wrote:
> 
>> 
>> 
>> 
>> On 5/18/11 4:19 AM, "Reinaldo Penno"  wrote:
>> 
>>> Senthil,
>>> 
>>> On 5/17/11 10:16 PM, "ssenthil"  wrote:
>>> 
>>>> Maybe I am confused, the logging draft in fact is attempting to specify
>>>> what
>>>> information elements are to be logged. It leaves it up to the
>>>> implementation
>>>> on choosing the transport (ipfix, netflow etc).
>>> 
>>> "   This document assumes that the NAT device will use some existing
>>>    framework like IPFIX, Netflow version 9 etc to send the log events to
>>>    the collector.
>>> "
>> Right, and the next sentence is
>> "  But it is beyond the scope of the document to define
>>    the framework to be used for logging.  However, the framework should
>>    support specifying a template that the NAT device will use to send
>>    its events. "
> 
> 'Template' is IPfix terminology. Logging format is outside the scope of
> logging document as you propose.
> 

Template is used in the context of sending the format and fields prior to
the data records, it helps the collector to be able to support multiple
templates. It is not implying usage of IPFIX.

>> 
>> The point of the above paragraph is that this document does not attempt to
>> define the framework and the implementation is free to choose its framework.
>> 
>>> 
>>> Also, The draft also posit that the format is binary
>>> 
>>> "   This document assumes that the NAT device will send the events in a
>>>    binary format to an off-box collector to be able to scale to carrier
>>>    grade NAT requirements but the formats (binary or ASCII) itself is
>>>    beyond the scope of this document.
>>> "
>>> 
>> [Senthil] You cant use ASCII to log events as it wouldn't scale, so I
>> assumed that you have binary. Is that restrictive? What other formats do you
>> think that may be the choices here?
> 
> That depends on the implementation. Some scale others do not. But Scale is
> out of the scope of this document as I understand.
> 
> A CGN box is one that has to deal with address sharing, whether for 10 or 1M
> subscribers the logging functionality problems are the same.
>
> Therefore let's focus on the information model.
> 
>> 
>>> And finally reuses Ipfix information IDs.
>>> 
>> 
>> [Senthil] Ah, this maybe the source of confusion. If I remove the IPFIX IDs
>> would that help your concerns?
>> 
>> Thanks
>> Senthil
>> 
>>> I'm looking for a draft scrubbed of these protocol specific language which
>>> defines the information model.
>>> 
>>> Thanks,
>>> 
>>> Reinaldo
>>> 
>> 
> 


From iljitsch@muada.com  Fri May 20 10:26:32 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 23E5CE0727 for ; Fri, 20 May 2011 10:26:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.97
X-Spam-Level: 
X-Spam-Status: No, score=-100.97 tagged_above=-999 required=5 tests=[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 IHgvkswi8tib for ; Fri, 20 May 2011 10:26: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 8FCD9E07E3 for ; Fri, 20 May 2011 10:26: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 p4KHRTuU077615 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 20 May 2011 19:27:30 +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: <3A4AC3EA076C4B6389C5E6F31CD9A16E@davidPC>
Date: Fri, 20 May 2011 19:26:22 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <2EED0FDF-14FE-49BE-BA13-AB15EC67250B@muada.com>
References: <3A4AC3EA076C4B6389C5E6F31CD9A16E@davidPC>
To: David Harrington 
X-Mailer: Apple Mail (2.1084)
Cc: draft-ietf-behave-ftp64@tools.ietf.org, behave@ietf.org, behave-chairs@tools.ietf.org
Subject: Re: [BEHAVE] AD review: draft-ietf-behave-ftp64-09
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, 20 May 2011 17:26:32 -0000

On 17 mei 2011, at 20:03, David Harrington wrote:

> I reviewed draft-ietf-behave-ftp64 and have a few questions.

Ok.

> 1) should security considerations discuss trust between client-alg and
> alg-server? I assume TLS cannot be used end-to-end for FTP, but must =
be
> hop-to-hop client-to-alg, and alg-to-server. Assuming different =
credentials
> apply, the secuirty association must be established between the client =
and the
> alg, not client-server, and the security association  must be =
established
> between the alg and server, not client-server. I would also assume =
that how this is
> accomplished depends on whether active or passive mode is being used =
to establish
> connections. The text as written might already already say that only =
passive
> mode is used in the presence of TLS protection, but I'm not sure that
> is what the text says. This might be made clearer.

What you describe is not the intended behavior. Hopefully this is =
clearer:

If the client issues the AUTH command, then the client is attempting to =
negotiate  security mechanisms which are =
likely to be incompatible with the FTP ALG function. For instance, if =
the client attempts to negotiate TLS protection of the control channel =
(, an ALG can do one of three things. It can =
transparently copy data transmitted over the control channel back and =
forth, so the TLS session works asexpected but the client commands and =
server responses are now hidden from the ALG. It can also block the =
negotiation of additional security, which will likely make the client =
and/or the server break off the session, or if not, perform actions in =
the clear thatwere supposed to be encrypted. The third option is to =
negotiate with both the clientand the server so two separate protected =
sessions are set up and the ALG is still ableto modify client commands =
and server responses. However, again clients and servers are likely to =
reject the session because this will be percieved as a man-in-the-middle =
attack.

An ALG MUST adopt the first option, and allow a client and a server to =
negotiatesecurity 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.

> 2) section 4 "As such, an ALG used with a stateful translator MUST =
support EPSV
> and MAY support EPRT. However, an ALG used with a stateless translator =
SHOULD
> also support EPRT. " Is there a requirement regarding stateless and =
EPSV?

Right, I've made that explicit:

Note that the translation of EPSV through all translators and EPRT =
through a stateless translator is relatively simple but supporting =
translation of EPRT through a stateful translator is relatively =
difficult, because in the latter case a translation mapping must be set =
up for each data transfer using parameters that must be learned from the =
client/server interaction over the control channel. This needs to happen =
before the EPRT command can be translated into a PORT command and passed =
on to the server. As such, an ALG used with a stateful translator MUST =
support EPSV translation and MAY support EPRT translation. However, an =
ALG used with a stateless translator MUST support EPSV translation and =
SHOULD also support EPRT translation.

> 3) in section 9, "Implementations SHOULD NOT try to detect the
> situation where both PASV and PORT commands are issued prior to a =
command that
> initiates a transfer, but rather, apply the same translation they =
would have if
> there had not been a PASV command prior to a PORT command or a PORT =
command
> prior to a PASV command. " I find this a bit ambiguous. Is it expected =
that the
> translation they would have done be based on having received only the =
second
> command (as if the first had not been received), or based on not =
having received
> either?

Ok, I changed the text to:

 allows a client to issue both PORT and PASV =
to use non-default ports on both sides of the connection. However, this =
is incompatible with the notion that with PASV, the data connection is =
made from the client to the server, while PORT reaffirms the default =
behavior where the server connects to the client. As such, the behavior =
of an ALG is undefined when a client issues both PASV and PORT. =
Implementations SHOULD NOT try to detect the situation where both PASV =
and PORT commands are issued prior to a command that initiates a =
transfer, but rather, translate commands as they occur. So if a client =
issues PASV, PASV is then translated to EPSV. If after that, before any =
transfers have occurred, the client issues PORT and the ALG supports =
PORT translation for this session, the ALG translates PORT to EPRT.

I could go on with a PORT first, PASV later example and explicitly say =
something about how regular garbage collection applies, but I don't want =
this extreme corner case to take up the better part of a page.

> 4) should the NOOP in section 12 be reflected in the ABNF algs-command
> ?

How would that work?

And is the text insufficient? I don't know off the top of my head but =
there could be several cases with conditionals where this applies, =
making for lengthy and/or ugly ABNF.

> 5) draft-liu-ftp64-extensions should be updated to
> draft-ietf-ftpext2-ftp64
> during subsequent processing.


> 6) The normative reference to ftpext2 work could cause this document
> to be held up in processing. is there a way to eliminate this =
reference? Can an
> implementation "support EPSV successfully" without this ftpext2
> extension? The text isn't clear that "successfully" means requiring =
support for an
> IPv4-IPv6 translation environment; that is only implied by the choice =
of
> reference [2428] vs [ftpext2].=20

The reference is only there to give credit, there is no dependency. I =
can remove it. (It's an informative reference, btw.)

Let me know about the above and I'll submit -10.

Iljitsch=

From internet-drafts@ietf.org  Fri May 20 12:44: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 BF0DEE075A; Fri, 20 May 2011 12:44:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.57
X-Spam-Level: 
X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 K4lrBSjBnSIR; Fri, 20 May 2011 12:44:16 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55A1EE06CD; Fri, 20 May 2011 12:44:16 -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.54
Message-ID: <20110520194416.30586.88564.idtracker@ietfa.amsl.com>
Date: Fri, 20 May 2011 12:44:16 -0700
Cc: behave@ietf.org
Subject: [BEHAVE] I-D Action: 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: Fri, 20 May 2011 19:44:16 -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-10.txt
	Pages           : 16
	Date            : 2011-05-20

   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 as best it can.

   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-10.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-10.txt

From iljitsch@muada.com  Fri May 20 12:46: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 AED8DE0762 for ; Fri, 20 May 2011 12:46:25 -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, 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 kF6ncvZhPJ5m for ; Fri, 20 May 2011 12:46: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 A9275E0715 for ; Fri, 20 May 2011 12:46:24 -0700 (PDT)
Received: from [IPv6:2001:470:1f0b:1289:223:12ff:fe56:36b2] ([IPv6:2001:470:1f0b:1289:223:12ff:fe56:36b2]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id p4KJlNJZ078279 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 20 May 2011 21:47:24 +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: <2EED0FDF-14FE-49BE-BA13-AB15EC67250B@muada.com>
Date: Fri, 20 May 2011 21:46:17 +0200
Content-Transfer-Encoding: 7bit
Message-Id: <5CBCD869-3619-4EAE-9D62-E3A020321338@muada.com>
References: <3A4AC3EA076C4B6389C5E6F31CD9A16E@davidPC> <2EED0FDF-14FE-49BE-BA13-AB15EC67250B@muada.com>
To: David Harrington 
X-Mailer: Apple Mail (2.1084)
Cc: draft-ietf-behave-ftp64@tools.ietf.org, "behave@ietf.orgWG WG" , "behave-chairs@tools.ietf.org Chairs" 
Subject: Re: [BEHAVE] AD review: draft-ietf-behave-ftp64-09
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, 20 May 2011 19:46:25 -0000

I have submitted -10 with the FTPEXT2 reference removed and no NOOP ABNF:

https://datatracker.ietf.org/doc/draft-ietf-behave-ftp64/

From dwing@cisco.com  Fri May 20 13:58:22 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 DC345E06BE for ; Fri, 20 May 2011 13:58:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.437
X-Spam-Level: 
X-Spam-Status: No, score=-110.437 tagged_above=-999 required=5 tests=[AWL=0.162, 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 0fGoa1jiO5oe for ; Fri, 20 May 2011 13:58:22 -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 49CE9E06AD for ; Fri, 20 May 2011 13:58:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2844; q=dns/txt; s=iport; t=1305925102; x=1307134702; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=NTA1Lx7agug2mAqMxx9s/rPpDiWZSm8qGAb9CwnzA+E=; b=AWXBn/RsPPLVu+6S7OhfJNczEJKAhwhRacr5C1uP+F+QZrnoC6OMVQAZ c+ftKU+FcOWlUnJP9b9hA9+HV02Qjmhbi9EZHC3MARIW/Ti4IuujXX/kf KOC0zHdvRM8y+mg8pS3mUVP6y9BUkutN1cCi7+KWJPAHxySsqev1p0fN2 Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AlsBAP3U1k2rRDoH/2dsb2JhbACXY0CBJIxYeKUBnXKGGQSGUJIMhko
X-IronPort-AV: E=Sophos;i="4.65,243,1304294400"; d="scan'208";a="701049071"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-6.cisco.com with ESMTP; 20 May 2011 20:58:22 +0000
Received: from dwingWS ([10.32.240.195]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4KKwLBE021190; Fri, 20 May 2011 20:58:21 GMT
From: "Dan Wing" 
To: 
References: 
In-Reply-To: 
Date: Fri, 20 May 2011 13:58:21 -0700
Message-ID: <08ce01cc1730$a74c0d30$f5e42790$@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: AcwLilLIKIq2VwJWRF2byj3d5YbRHQLpkErg
Content-Language: en-us
Cc: jouni.nospam@gmail.com, behave-chairs@tools.ietf.org
Subject: Re: [BEHAVE] adoption of learn analysis and DNS-based NAT64 prefix discovery
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, 20 May 2011 20:58:23 -0000

Based on the in-room consensus at IETF80 and one 'yes' on the list, I will
ask the authors to submit the documents as BEHAVE working group items.

-d


> -----Original Message-----
> From: Dan Wing [mailto:dwing@cisco.com]
> Sent: Thursday, May 05, 2011 6:10 PM
> To: 'behave@ietf.org'
> Cc: 'teemu.savolainen@nokia.com'; 'jouni.nospam@gmail.com'; 'behave-
> chairs@tools.ietf.org'
> Subject: adoption of learn analysis and DNS-based NAT64 prefix
> discovery
> 
> At IETF80, we appeared to have reach regarding BEHAVE's milestone "Apr
> 2011 - Submit to IESG: avoiding NAT64 with dual-stack host for local
> networks (std)".  Excerpt from the minutes is below.  Under this
> milestone, it seems valuable to publish two documents:  one which
> analyzes the various approaches, and another that details the specific
> recommended approach.
> 
> To that end, please provide feedback to behave@ietf.org on adopting the
> following two documents as working group documents:
> 
> 1.  draft-korhonen-behave-nat64-learn-analysis, to be informational
>     http://tools.ietf.org/html/draft-korhonen-behave-nat64-learn-
> analysis-02
> 
> 2.  draft-savolainen-heuristic-nat64-discovery, likely to be standards
> track
>     or possibly informational
>     http://tools.ietf.org/html/draft-savolainen-heuristic-nat64-
> discovery-01
> 
> Thanks,
> -d
> 
> -----
> 
> http://www.ietf.org/proceedings/80/minutes/behave.txt
> 
> ...
> Avoiding NAT64 with dual-stack host for local networks (Jouni Korhonen)
>        draft-korhonen-edns0-synthesis-flag
>        draft-savolainen-heuristic-nat64-discovery
>        draft-korhonen-behave-nat64-learn-analysis
>        milestone date: April 2011
> 
> Dan Wing: Should we use DNS well-known-name (hack) or the ENDS0 option
> (more elegant)
> 
> Andrew Sullivan: Are there implementations of NAT64 that don't
> currently implement the ENDS0 option?
> 
> Mark Andrews: BIND does not currently have the ENDS0 option but could
> easily add it
> 
> Andrew Sullivan: Needs to be done quickly
> 
> Matthew Kaufman: What about client resolver APIs that don't support
> getting to the EDNS0 option?
> 
> Stuart Cheshire: What software needs to learn the prefix? Client DNS
> resolver, or other application software?
> 
> Dave Thaler: Other application software.
> 
> Stuart Cheshire: Then the resolver API limitation might be a problem.
> 
> Andrew Sullivan: Standardizing a DNS well-known-name will be an uphill
> struggle
> 
> Andrew Sullivan: We should pick one and do it, not both.
> 
> Dave Thaler: If DNS well-known-name, we need to decide if it's a single
> global well-known-name, or per-operator, or per vendor?
> 
> Matthew Kaufman: This will happen. Better to synthesize locally than to
> store in the DNS far away.
> ...
> 
> 



From iesg-secretary@ietf.org  Fri May 20 15:48:14 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 78A56E06EB; Fri, 20 May 2011 15:48:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.543
X-Spam-Level: 
X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 l7YcjblUrllg; Fri, 20 May 2011 15:48:13 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE1DFE06A2; Fri, 20 May 2011 15:48:13 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG 
To: IETF-Announce 
X-Test-IDTracker: no
X-IETF-IDTracker: 3.54
Message-ID: <20110520224813.2156.61466.idtracker@ietfa.amsl.com>
Date: Fri, 20 May 2011 15:48:13 -0700
Cc: behave@ietf.org
Subject: [BEHAVE] 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
Reply-To: ietf@ietf.org
List-Id: mailing list of BEHAVE IETF WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 May 2011 22:48:14 -0000

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

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-06-03. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   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 as best it can.

   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.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-behave-ftp64/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-behave-ftp64/


The following IPR Declarations may be related to this I-D:

   http://datatracker.ietf.org/ipr/1322/

IPR has been disclosed and announced to the mailing list,
https://datatracker.ietf.org/ipr/search/?option=document_search&document_sea
rch=draft-ietf-behave-ftp64
and there has been no subsequent WG discussion about this IPR disclosure.



From prondou@gmail.com  Tue May 24 08:47: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 96FC2E0752; Tue, 24 May 2011 08:47:02 -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 7FEvUsPEB-8g; Tue, 24 May 2011 08:47:02 -0700 (PDT)
Received: from mailrelay011.isp.belgacom.be (mailrelay011.isp.belgacom.be [195.238.6.178]) by ietfa.amsl.com (Postfix) with ESMTP id 81637E0755; Tue, 24 May 2011 08:47:01 -0700 (PDT)
X-Belgacom-Dynamic: yes
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApIBAEDR201R95HQ/2dsb2JhbAAMhFGrNK9GPIcdN4hngSuDaYEHBJAfjwM
Received: from 208.145-247-81.adsl-dyn.isp.belgacom.be (HELO [192.168.1.40]) ([81.247.145.208]) by relay.skynet.be with ESMTP; 24 May 2011 17:46:56 +0200
Message-ID: <4DDBD2F1.3020704@gmail.com>
Date: Tue, 24 May 2011 17:46:57 +0200
From: Pierre Rondou 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11
MIME-Version: 1.0
To: Eric Dumazet 
References: <4DC1FACC.4080204@gmail.com> <1306248975.3026.47.camel@edumazet-laptop>
In-Reply-To: <1306248975.3026.47.camel@edumazet-laptop>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: v6ops@ietf.org, behave@ietf.org, Cyril Soldani , netfilter-devel@vger.kernel.org, guy.leduc@ulg.ac.be, evyncke@cisco.com
Subject: Re: [BEHAVE] Netfilter Module for NAT IVI available
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, 24 May 2011 15:47:02 -0000

Le 24/05/11 16:56, Eric Dumazet a écrit :
> Le jeudi 05 mai 2011 à 03:18 +0200, Pierre Rondou a écrit :
>    
>> Hello everybody,
>>
>> I'm currently a student at the University of Liège. As part of my master
>> thesis, I have to develop a Linux kernel module for IVI (
>> http://datatracker.ietf.org/doc/rfc6219/ ).
>>
>> I now consider my module as finished (i.e, all functionalities are
>> implemented) and publish it.
>>
>> It is available on sourceforge:
>>
>> http://sourceforge.net/projects/nativi/
>>
>> Feel free to test it and report to me any bug, bad implementation,
>> error, ...
>>
>> If you believe that this module can be included is the Linux Kernel or
>> in the Xtables-addons framework, I'll be glad and will help you in this
>> task.
>>
>>
>> I have tested my module inside the Xtables-addons framework (version
>> 1.32) on a debian squeeze (6.0.1) linux with a 2.6.32-5  kernel (i686).
>>
>> Because of the lack of "EXPORT_SYMBOL" in the kernel, I had to
>> copy-paste several functions from the kernel into the
>> nativi_kernel_code.c file in order to use some features already
>> available in the kernel (ip_finish_output, ip6_output, icmp_send).
>>
>> Documentation is provided in the source code, if you have any question
>> don't hesitate to ask me.
>>
>>      
> Hi Pierre
>
> 1) Are you sure netfilter is the right place for this IVI feature ?
>     (fact that you had to copy/paste ~1300 lines of code from kernel
> might show that this would be better to use a module hooked into
> forwarding stack ?)
>    
I used Xtables to produce my module, fact is that I was (and still am) a 
kernel nooby, Xtables seemed to a be good way to produce this code.
I'm not sure to what you're refering about, are you suggesting I should 
have developed the module directly into the kernel?

> 2) How this can integrate a {conntrack enabled} firewall ?
>
>    

I can't ... It's a drawback of the module. The fact is that I only have 
found a very little documentation about conntrack code, so I dropped the 
idea of dealing with it.
But it shouldn't be difficult to update the conntrack for a kernel pro I 
guess ;-)

Regards,

Pierre

From prondou@gmail.com  Wed May 25 05:59: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 D7695130017; Wed, 25 May 2011 05:59: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 qQSBnvES-0IO; Wed, 25 May 2011 05:59:49 -0700 (PDT)
Received: from mailrelay008.isp.belgacom.be (mailrelay008.isp.belgacom.be [195.238.6.174]) by ietfa.amsl.com (Postfix) with ESMTP id 041E0E067C; Wed, 25 May 2011 05:59:48 -0700 (PDT)
X-Belgacom-Dynamic: yes
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApIBABb73E1R95HQ/2dsb2JhbAAMhFDXMzyHHzmIZ4Erg2qBBwSQLo8J
Received: from 208.145-247-81.adsl-dyn.isp.belgacom.be (HELO [192.168.1.40]) ([81.247.145.208]) by relay.skynet.be with ESMTP; 25 May 2011 14:59:47 +0200
Message-ID: <4DDCFD42.3010708@gmail.com>
Date: Wed, 25 May 2011 14:59:46 +0200
From: Pierre Rondou 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11
MIME-Version: 1.0
To: Eric Dumazet 
References: <4DC1FACC.4080204@gmail.com>	 <1306248975.3026.47.camel@edumazet-laptop> <4DDBD2F1.3020704@gmail.com> <1306252554.3026.66.camel@edumazet-laptop>
In-Reply-To: <1306252554.3026.66.camel@edumazet-laptop>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: v6ops@ietf.org, behave@ietf.org, Cyril Soldani , netfilter-devel@vger.kernel.org, guy.leduc@ulg.ac.be, evyncke@cisco.com
Subject: Re: [BEHAVE] Netfilter Module for NAT IVI available
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, 25 May 2011 12:59:49 -0000

Le 24/05/11 17:55, Eric Dumazet a écrit :
>
>>>>
>>>>          
>>> Hi Pierre
>>>
>>> 1) Are you sure netfilter is the right place for this IVI feature ?
>>>      (fact that you had to copy/paste ~1300 lines of code from kernel
>>> might show that this would be better to use a module hooked into
>>> forwarding stack ?)
>>>
>>>        
>> I used Xtables to produce my module, fact is that I was (and still am) a
>> kernel nooby, Xtables seemed to a be good way to produce this code.
>> I'm not sure to what you're refering about, are you suggesting I should
>> have developed the module directly into the kernel?
>>
>>      
> We all were kernel newbie at very beginning ;)
>    

Sure, unfortunately there is no real book to teach new coders on what 
they should do.

>    
>>> 2) How this can integrate a {conntrack enabled} firewall ?
>>>
>>>
>>>        
>> I can't ... It's a drawback of the module. The fact is that I only have
>> found a very little documentation about conntrack code, so I dropped the
>> idea of dealing with it.
>> But it shouldn't be difficult to update the conntrack for a kernel pro I
>> guess ;-)
>>      
> This has to be discussed before even coding ;)
>
> One packet going through this gateway has one IPv6 side and one ipv4
> side. This can be a problem to firewalling (either its ipv4, either its
> ipv6) and conntracking.
>
>
>    

It is a problem that's sure.
But as stated before, I didn't any suitable conntrack doc :(
My main thesis goal is to provide a working module, conntrack support 
would be a bonus, but for now, I cannot do it on my own because of a 
lack of conntrack knowledge.

From internet-drafts@ietf.org  Wed May 25 10:51: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 5E919E0728; Wed, 25 May 2011 10:51:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hL6Gsp7FjhgA; Wed, 25 May 2011 10:51:21 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC35E0686; Wed, 25 May 2011 10:51:21 -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: <20110525175121.5909.86239.idtracker@ietfa.amsl.com>
Date: Wed, 25 May 2011 10:51:21 -0700
Cc: behave@ietf.org
Subject: [BEHAVE] I-D Action: draft-ietf-behave-nat64-learn-analysis-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, 25 May 2011 17:51:23 -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           : Analysis of solution proposals for hosts to learn NAT64 =
prefix
	Author(s)       : Jouni Korhonen
                          Teemu Savolainen
	Filename        : draft-ietf-behave-nat64-learn-analysis-00.txt
	Pages           : 25
	Date            : 2011-05-25

   Hosts and applications may benefit from the knowledge if an IPv6
   address is synthesized, which would mean a NAT64 is used to reach the
   IPv4 network or Internet.  This document analyses a number of
   proposed solutions for communicating whether the synthesis is taking
   place, used address format, and the IPv6 prefix used by the NAT64 and
   DNS64.  The solutions enable both NAT64 avoidance and intentional
   utilization by allowing local IPv6 address synthesis.  The document
   concludes by recommending selection of heuristic discovery based
   solution.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-behave-nat64-learn-analysis-=
00.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-nat64-learn-analysis-0=
0.txt

From internet-drafts@ietf.org  Wed May 25 10:53: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 DC693E0686; Wed, 25 May 2011 10:53:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oqDz0vG-4F2Z; Wed, 25 May 2011 10:53:36 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7E6E0684; Wed, 25 May 2011 10:53:36 -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: <20110525175336.5856.5752.idtracker@ietfa.amsl.com>
Date: Wed, 25 May 2011 10:53:36 -0700
Cc: behave@ietf.org
Subject: [BEHAVE] I-D Action: 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, 25 May 2011 17:53:37 -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-00.txt
	Pages           : 7
	Date            : 2011-05-25

   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-00.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-nat64-discovery-heuris=
tic-00.txt

From mcr@sandelman.ca  Wed May 25 14:00: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 4D715E0703 for ; Wed, 25 May 2011 14:00:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.954
X-Spam-Level: 
X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334]
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 w8TufInznFvk for ; Wed, 25 May 2011 14:00:40 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 54242E06E5 for ; Wed, 25 May 2011 14:00:39 -0700 (PDT)
Received: from marajade.sandelman.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 1DDE2340B4; Wed, 25 May 2011 17:00:39 -0400 (EDT)
Received: from marajade.sandelman.ca (marajade.sandelman.ca [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 0565A980ED; Wed, 25 May 2011 17:02:10 -0400 (EDT)
From: Michael Richardson 
To: behave@ietf.org
X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 22)
Date: Wed, 25 May 2011 17:02:09 -0400
Message-ID: <14353.1306357329@marajade.sandelman.ca>
Sender: mcr@sandelman.ca
Cc: jouni.nospam@gmail.com
Subject: [BEHAVE] behave-nat64-learn-analysis-00, issue #2
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, 25 May 2011 21:00:41 -0000

Thank you for this document!


Change/add text:

   Secondly, finding out how to construct from an IPv4 address an IPv6
   address that will be routable to/by the NAT64.  This is useful when
   IPv4 literals can be found in the payload of some protocol or
   applications do not use DNS to resolve names to addresses but know
   the IPv4 address of the destination by some other means.  We will
   refer this as 'Issue #2' throughout the document.

to:

*  Secondly, finding out how, and if, to construct from an IPv4 address an IPv6
   address that will be routable to/by the NAT64.  This is useful when
   IPv4 literals can be found in the payload of some protocol or
   applications do not use DNS to resolve names to addresses but know
*  the IPv4 address of the destination by some other means.    Any host
*  which is using a local recursive resolver (such as to do provide
*  DNSSEC or due to split-horizon DNS) will want to do it's own DNS64
*  synthesis.  We will refer this as 'Issue #2' throughout the document.


I think that section 3 lists DNSSEC as one of the first items, but until
I got there I couldn't be sure if it was in fact part of issue #2.

Change:

   Issue #4
      The problem of supporting changing NSP.  The NSP learned by the
      host may become stale for multiple reasons.  For example, the host
      might move to a new network that uses different NSP, thus making
      the previously learned NSP stale.  Also, the NSP used in the
      network may be changed due administrative reasons, thus again
      making previously learned NSP stale.

to:

   Issue #4
      The problem of supporting changing NSP.  The NSP learned by the
      host may become stale for multiple reasons.  For example, the host
*     might move to a new network that uses different NSP (or which 
*     provides no NSP), thus making the previously learned NSP stale.
      Also, the NSP used in the network may be changed due
      administrative reasons, thus again making previously learned NSP stale.

====

section 4.1.2:
   - fails if a host is doing .-anchored recursive lookups.
   - mobile and DNSSEC-aware hosts are much more likely to do this.
   - It's not that the host is "Issue #3", it uses DNS, but it doesn't
     use the DNS server that the "ISP" tells them to use.

section 4.2 duplicate of section 4.1?

section 4.5, wing-behave-learn-prefix's U-NAPTR solution seems like a
        very good solution, but requires that the ISP have reverse DNS.
        (mentioned in CONs.  But, I note that if the DNS64 machine is
        actually the one queried and DNSSEC is not validated, then 
        it does not require the reverse zone to actually be properly
        delegated)

section 4.7, RA-Learn-Prefix is, I think, a MUST for the future. 
        It's the architecturally sensible solution.


section 5, I don't understand how a local DNSSEC recursive resolver
        works if Issue #3 is not solved.  Such a host does not, from
        the point of view of the DNS64, "use DNS".




From pekkas@netcore.fi  Mon May 30 02:10: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 7D290E06D8; Mon, 30 May 2011 02:10:31 -0700 (PDT)
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, 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 duFXAbEWoo-N; Mon, 30 May 2011 02:10:30 -0700 (PDT)
Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by ietfa.amsl.com (Postfix) with ESMTP id 22449E06EA; Mon, 30 May 2011 02:10:29 -0700 (PDT)
Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id p4U9AN92013350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 May 2011 12:10:23 +0300
Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id p4U9ANwC013347; Mon, 30 May 2011 12:10:23 +0300
Date: Mon, 30 May 2011 12:10:23 +0300 (EEST)
From: Pekka Savola 
To: ietf@ietf.org
In-Reply-To: <20110520224813.2156.61466.idtracker@ietfa.amsl.com>
Message-ID: 
References: <20110520224813.2156.61466.idtracker@ietfa.amsl.com>
User-Agent: Alpine 2.02 (LRH 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Virus-Scanned: clamav-milter 0.97 at otso.netcore.fi
X-Virus-Status: Clean
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
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, 30 May 2011 09:10:31 -0000

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?

From teemu.savolainen@nokia.com  Mon May 30 04:56:10 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 3452DE07A4 for ; Mon, 30 May 2011 04:56:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.099
X-Spam-Level: 
X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500,  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 klHJZUPmX2q8 for ; Mon, 30 May 2011 04:56:08 -0700 (PDT)
Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id B6EBFE0714 for ; Mon, 30 May 2011 04:56:08 -0700 (PDT)
Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p4UBu2Qe011578 for ; Mon, 30 May 2011 14:56:07 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 30 May 2011 14:56:06 +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; Mon, 30 May 2011 13:56:05 +0200
Received: from 008-AM1MPN1-036.mgdnok.nokia.com ([169.254.6.209]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0289.008; Mon, 30 May 2011 13:56:05 +0200
From: 
To: 
Thread-Topic: Next for draft-ietf-behave-nat64-discovery-heuristic-00.txt
Thread-Index: Acwevpw8zf4ZcYbGSIma0tKrdgjVhg==
Date: Mon, 30 May 2011 11:56:04 +0000
Message-ID: <916CE6CF87173740BC8A2CE44309696205EE34@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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 30 May 2011 11:56:06.0224 (UTC) FILETIME=[8E9EFD00:01CC1EC0]
X-Nokia-AV: Clean
Subject: [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: Mon, 30 May 2011 11:56:10 -0000

Hi,

The -00 revision was uploaded pretty much as is. I'm looking forward to nex=
t updates to the draft, and I thought those might be as follows:=20

1) Clarify that the well-known FQDN is to be specified and hosted by IANA

2) Ask for a dedicated non-routable IPv4 address for the well-known FQDN

3) Define long TTL for the well-known name entry so that it can be cached e=
fficiently

4) Define that the synthesizing DNS64 must handle AAAA query for the well-k=
nown FQDN as for any other FQDN that does not have AAAA record (=3Dsynthesi=
ze response normally). However, A DNS server that does not implement AAAA s=
ynthesis (DNS64 function) could directly respond NXDOMAIN for the query ins=
tead of forwarding the (in that case pointless) query towards root?=20

5) Possibly connectivity test conducted after synthesis is to be made to ap=
plications' own servers, if required.

6) The name shall be queried again when the lifetime of previous response e=
xpires (as was set by DNS64) or if interface changes.

Feedback welcome, as always. I plan to make an updated version by mid-June =
latest.

Best regards,

	Teemu


> -----Original Message-----
> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf
> Of ext internet-drafts@ietf.org
> Sent: 25. toukokuuta 2011 20:54
> To: i-d-announce@ietf.org
> Cc: behave@ietf.org
> Subject: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic=
-00.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-00.txt
> 	Pages           : 7
> 	Date            : 2011-05-25
>=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-
> 00.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-
> 00.txt
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave

From ajs@anvilwalrusden.com  Mon May 30 05:04: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 40B71E07B2 for ; Mon, 30 May 2011 05:04:59 -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 vmlAHiuUSBii for ; Mon, 30 May 2011 05:04:58 -0700 (PDT)
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id EBF96E07A4 for ; Mon, 30 May 2011 05:04: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 9D66D1ECB41C for ; Mon, 30 May 2011 12:04:56 +0000 (UTC)
Date: Mon, 30 May 2011 08:04:55 -0400
From: Andrew Sullivan 
To: behave@ietf.org
Message-ID: <20110530120455.GD22844@shinkuro.com>
References: <916CE6CF87173740BC8A2CE44309696205EE34@008-AM1MPN1-036.mgdnok.nokia.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <916CE6CF87173740BC8A2CE44309696205EE34@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: Mon, 30 May 2011 12:04:59 -0000

On Mon, May 30, 2011 at 11:56:04AM +0000, teemu.savolainen@nokia.com wrote: 

> 4) Define that the synthesizing DNS64 must handle AAAA query for the
> well-known FQDN as for any other FQDN that does not have AAAA record
> (=synthesize response normally). However, A DNS server that does not
> implement AAAA synthesis (DNS64 function) could directly respond
> NXDOMAIN for the query instead of forwarding the (in that case
> pointless) query towards root?

That would be nice.  See
http://tools.ietf.org/html/draft-ietf-dnsop-default-local-zones-15
(which is, I think, about to be published).

(Just for the record, any contribution I make to this effort doesn't
mean I think it's a good idea.  I think it's a bad idea, but it's
apparently the bad idea that people are going to implement anyway.  So
I'd like it to be least bad.  It's still a bad idea.)

A

-- 
Andrew Sullivan
ajs@crankycanuck.ca

From teemu.savolainen@nokia.com  Mon May 30 05:58: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 DCD73E0651 for ; Mon, 30 May 2011 05:58:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.266
X-Spam-Level: 
X-Spam-Status: No, score=-3.266 tagged_above=-999 required=5 tests=[AWL=0.334,  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 ZA2m22rzCsf0 for ; Mon, 30 May 2011 05:58:58 -0700 (PDT)
Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 21FC3E07CD for ; Mon, 30 May 2011 05:58:58 -0700 (PDT)
Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p4UCwaC3015068; Mon, 30 May 2011 15:58:55 +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);  Mon, 30 May 2011 15:58:49 +0300
Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 30 May 2011 14:58:48 +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; Mon, 30 May 2011 14:58:48 +0200
From: 
To: , 
Thread-Topic: [BEHAVE] Next for draft-ietf-behave-nat64-discovery-heuristic-00.txt
Thread-Index: Acwevpw8zf4ZcYbGSIma0tKrdgjVhv//5NSA///RbTA=
Date: Mon, 30 May 2011 12:58:47 +0000
Message-ID: <916CE6CF87173740BC8A2CE44309696205EF97@008-AM1MPN1-036.mgdnok.nokia.com>
References: <916CE6CF87173740BC8A2CE44309696205EE34@008-AM1MPN1-036.mgdnok.nokia.com> <20110530120455.GD22844@shinkuro.com>
In-Reply-To: <20110530120455.GD22844@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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 30 May 2011 12:58:49.0225 (UTC) FILETIME=[518B5F90:01CC1EC9]
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: Mon, 30 May 2011 12:58:59 -0000

Thank you, we shall reference that document.

On the query frequency, we could state also that the DNS64 discovery is to =
be performed only on-demand, e.g. as result of API call and not pre-emptive=
ly.

	Teemu


> -----Original Message-----
> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf
> Of ext Andrew Sullivan
> Sent: 30. toukokuuta 2011 15:05
> To: behave@ietf.org
> Subject: Re: [BEHAVE] Next for draft-ietf-behave-nat64-discovery-heuristi=
c-
> 00.txt
>=20
> On Mon, May 30, 2011 at 11:56:04AM +0000, teemu.savolainen@nokia.com
> wrote:
>=20
> > 4) Define that the synthesizing DNS64 must handle AAAA query for the
> > well-known FQDN as for any other FQDN that does not have AAAA record
> > (=3Dsynthesize response normally). However, A DNS server that does not
> > implement AAAA synthesis (DNS64 function) could directly respond
> > NXDOMAIN for the query instead of forwarding the (in that case
> > pointless) query towards root?
>=20
> That would be nice.  See
> http://tools.ietf.org/html/draft-ietf-dnsop-default-local-zones-15
> (which is, I think, about to be published).
>=20
> (Just for the record, any contribution I make to this effort doesn't mean=
 I think
> it's a good idea.  I think it's a bad idea, but it's apparently the bad i=
dea that
> people are going to implement anyway.  So I'd like it to be least bad.  I=
t's still a
> bad idea.)
>=20
> A
>=20
> --
> Andrew Sullivan
> ajs@crankycanuck.ca
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave

From ajs@anvilwalrusden.com  Mon May 30 06:32:42 2011
Return-Path: 
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 846CAE074C for ; Mon, 30 May 2011 06:32:42 -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 y7b0v0qQHEOL for ; Mon, 30 May 2011 06:32:41 -0700 (PDT)
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id D0212E0651 for ; Mon, 30 May 2011 06:32:41 -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 A57761ECB41C for ; Mon, 30 May 2011 13:32:40 +0000 (UTC)
Date: Mon, 30 May 2011 09:32:39 -0400
From: Andrew Sullivan 
To: behave@ietf.org
Message-ID: <20110530133238.GE22844@shinkuro.com>
References: <916CE6CF87173740BC8A2CE44309696205EE34@008-AM1MPN1-036.mgdnok.nokia.com> <20110530120455.GD22844@shinkuro.com> <916CE6CF87173740BC8A2CE44309696205EF97@008-AM1MPN1-036.mgdnok.nokia.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <916CE6CF87173740BC8A2CE44309696205EF97@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: Mon, 30 May 2011 13:32:42 -0000

On Mon, May 30, 2011 at 12:58:47PM +0000, teemu.savolainen@nokia.com wrote:
> 
> On the query frequency, we could state also that the DNS64 discovery is to be performed only on-demand, e.g. as result of API call and not pre-emptively.
> 

I'm not sure that's actually the best advice.  It strikes me that the
system resolver subsystem might want to do this one time, whenever the
network topology changes (cf. the mif DNS work).

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.ca

From teemu.savolainen@nokia.com  Mon May 30 06:57:09 2011
Return-Path: 
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0B33E07C8 for ; Mon, 30 May 2011 06:57:09 -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 WzQrOyC7EYuJ for ; Mon, 30 May 2011 06:57:09 -0700 (PDT)
Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id F0D6FE06FD for ; Mon, 30 May 2011 06:57:08 -0700 (PDT)
Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p4UDuo2g006344; Mon, 30 May 2011 16:57:06 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 30 May 2011 16:57:02 +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; Mon, 30 May 2011 15:57:02 +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; Mon, 30 May 2011 15:57:01 +0200
From: 
To: , 
Thread-Topic: [BEHAVE] Next for draft-ietf-behave-nat64-discovery-heuristic-00.txt
Thread-Index: Acwevpw8zf4ZcYbGSIma0tKrdgjVhv//5NSA///RbTCAAEcWgIAAKFU1
Date: Mon, 30 May 2011 13:57:00 +0000
Message-ID: <916CE6CF87173740BC8A2CE44309696205F059@008-AM1MPN1-036.mgdnok.nokia.com>
References: <916CE6CF87173740BC8A2CE44309696205EE34@008-AM1MPN1-036.mgdnok.nokia.com> <20110530120455.GD22844@shinkuro.com> <916CE6CF87173740BC8A2CE44309696205EF97@008-AM1MPN1-036.mgdnok.nokia.com>, <20110530133238.GE22844@shinkuro.com>
In-Reply-To: <20110530133238.GE22844@shinkuro.com>
Accept-Language: en-US
Content-Language: en-GB
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 May 2011 13:57:02.0382 (UTC) FILETIME=[73A0D4E0:01CC1ED1]
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: Mon, 30 May 2011 13:57:09 -0000

Maybe implementation detail then..

Sent from my Windows Phone

-----Original Message-----
From: ext Andrew Sullivan
Sent: 30 May 2011 16:32
To: behave@ietf.org
Subject: Re: [BEHAVE] Next for draft-ietf-behave-nat64-discovery-heuristic-=
00.txt


On Mon, May 30, 2011 at 12:58:47PM +0000, teemu.savolainen@nokia.com wrote:
>
> On the query frequency, we could state also that the DNS64 discovery is t=
o be performed only on-demand, e.g. as result of API call and not pre-empti=
vely.
>

I'm not sure that's actually the best advice.  It strikes me that the
system resolver subsystem might want to do this one time, whenever the
network topology changes (cf. the mif DNS work).

A

--
Andrew Sullivan
ajs@anvilwalrusden.ca
_______________________________________________
Behave mailing list
Behave@ietf.org
https://www.ietf.org/mailman/listinfo/behave

From cb.list6@gmail.com  Mon May 30 07:59: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 751FAE078E for ; Mon, 30 May 2011 07:59:36 -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 dHETGkqCZ-0y for ; Mon, 30 May 2011 07:59:35 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 39000E0677 for ; Mon, 30 May 2011 07:59:35 -0700 (PDT)
Received: by wwa36 with SMTP id 36so2733537wwa.13 for ; Mon, 30 May 2011 07:59:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=miQASdlZiqG182ZXYLclB61XupaKTvzkIbxHz+KXVa0=; b=x5zNIkNhX7F91FZO/Q3cdhw60GJhPL/fmfVNI1WTa++7zLg3iAmi4CqcplrWiHgk0f 1O5te0jT6OdWF4Rv28Dz5J/jVghU5aRG00afVXZCy8V0XolyCc1USDSuuUSzjBGaKt2u +ccAbaK/jPe9P2KIomFGwmaPyr/VASS/CrNx4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=gUSb5e6vMSy4xg+GOfs6vMsk8ADjaKry5gNykP57/10pNE+Oyo617wqGWpAHZq6UTH l5pQMoK9LofyT9/tn3crwRrV9PY0mhc0ABIboU67L8VQj8GOMOS3sPtyeVOy0AAThqWW eP91XIHqQESfEnS50OqI98kNnVHqJz89C1hT0=
MIME-Version: 1.0
Received: by 10.216.65.203 with SMTP id f53mr2821904wed.54.1306767574201; Mon, 30 May 2011 07:59:34 -0700 (PDT)
Received: by 10.216.179.199 with HTTP; Mon, 30 May 2011 07:59:34 -0700 (PDT)
Received: by 10.216.179.199 with HTTP; Mon, 30 May 2011 07:59:34 -0700 (PDT)
In-Reply-To: <916CE6CF87173740BC8A2CE44309696205EE34@008-AM1MPN1-036.mgdnok.nokia.com>
References: <916CE6CF87173740BC8A2CE44309696205EE34@008-AM1MPN1-036.mgdnok.nokia.com>
Date: Mon, 30 May 2011 07:59:34 -0700
Message-ID: 
From: Cameron Byrne 
To: teemu.savolainen@nokia.com
Content-Type: multipart/alternative; boundary=000e0ce0b4ea10768f04a47f893b
Cc: behave@ietf.org
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: Mon, 30 May 2011 14:59:36 -0000

--000e0ce0b4ea10768f04a47f893b
Content-Type: text/plain; charset=ISO-8859-1

On May 30, 2011 4:56 AM,  wrote:
>
> Hi,
>
> The -00 revision was uploaded pretty much as is. I'm looking forward to
next updates to the draft, and I thought those might be as follows:
>
> 1) Clarify that the well-known FQDN is to be specified and hosted by IANA
>
> 2) Ask for a dedicated non-routable IPv4 address for the well-known FQDN
>
> 3) Define long TTL for the well-known name entry so that it can be cached
efficiently
>
> 4) Define that the synthesizing DNS64 must handle AAAA query for the
well-known FQDN as for any other FQDN that does not have AAAA record
(=synthesize response normally). However, A DNS server that does not
implement AAAA synthesis (DNS64 function) could directly respond NXDOMAIN
for the query instead of forwarding the (in that case pointless) query
towards root?
>

I don't think this will be an impact, but I would like to caution that many
service providers sends redirects to ad pages and do not send NXDOMAIN to
customers.  My cable company does this. As worded, this should not be an
impact, I just want to avoid people writing code here that depend on seeing
NXDOMAIN that will never come.

Cb

> 5) Possibly connectivity test conducted after synthesis is to be made to
applications' own servers, if required.
>
> 6) The name shall be queried again when the lifetime of previous response
expires (as was set by DNS64) or if interface changes.
>
> Feedback welcome, as always. I plan to make an updated version by mid-June
latest.
>
> Best regards,
>
>        Teemu
>
>
> > -----Original Message-----
> > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf
> > Of ext internet-drafts@ietf.org
> > Sent: 25. toukokuuta 2011 20:54
> > To: i-d-announce@ietf.org
> > Cc: behave@ietf.org
> > Subject: [BEHAVE] I-D Action:
draft-ietf-behave-nat64-discovery-heuristic-00.txt
> >
> > 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           : Discovery of a Network-Specific NAT64 Prefix
using a Well-
> > Known Name
> >       Author(s)       : Teemu Savolainen
> >                           Jouni Korhonen
> >       Filename        :
draft-ietf-behave-nat64-discovery-heuristic-00.txt
> >       Pages           : 7
> >       Date            : 2011-05-25
> >
> >    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-heuristic-
> > 00.txt
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > This Internet-Draft can be retrieved at:
> >
ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-nat64-discovery-heuristic-
> > 00.txt
> > _______________________________________________
> > Behave mailing list
> > Behave@ietf.org
> > https://www.ietf.org/mailman/listinfo/behave
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave

--000e0ce0b4ea10768f04a47f893b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable




On May 30, 2011 4:56 AM, <=
teemu.savolainen@nokia.com> wrote:

>

> Hi,

>

> The -00 revision was uploaded pretty much as is. I'm looking forwa=
rd to next updates to the draft, and I thought those might be as follows:
>

> 1) Clarify that the well-known FQDN is to be specified and hosted by I=
ANA

>

> 2) Ask for a dedicated non-routable IPv4 address for the well-known FQ=
DN

>

> 3) Define long TTL for the well-known name entry so that it can be cac=
hed efficiently

>

> 4) Define that the synthesizing DNS64 must handle AAAA query for the w=
ell-known FQDN as for any other FQDN that does not have AAAA record (=3Dsyn=
thesize response normally). However, A DNS server that does not implement A=
AAA synthesis (DNS64 function) could directly respond NXDOMAIN for the quer=
y instead of forwarding the (in that case pointless) query towards root?

>


I don't think this will be an impact, but I would like to caution th=
at many service providers sends redirects to ad pages and do not send NXDOM=
AIN to customers.=A0 My cable company does this. As worded, this should not=
 be an impact, I just want to avoid people writing code here that depend on=
 seeing NXDOMAIN that will never come.




Cb


> 5) Possibly connectivity test conducted after synthesis is to be ma=
de to applications' own servers, if required.

>

> 6) The name shall be queried again when the lifetime of previous respo=
nse expires (as was set by DNS64) or if interface changes.

>

> Feedback welcome, as always. I plan to make an updated version by mid-=
June latest.

>

> Best regards,

>

> =A0 =A0 =A0 =A0Teemu

>

>

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

> > From: behave-bounces@i=
etf.org [mailto:behave-bounc=
es@ietf.org] On Behalf

> > Of ext internet-draft=
s@ietf.org

> > Sent: 25. toukokuuta 2011 20:54

> > To: i-d-announce@ietf.or=
g

> > Cc: behave@ietf.org

> > Subject: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-h=
euristic-00.txt

> >

> > A New Internet-Draft is available from the on-line Internet-Draft=
s directories.

> > This draft is a work item of the Behavior Engineering for Hindran=
ce Avoidance

> > Working Group of the IETF.

> >

> > =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Discovery of a Network-Sp=
ecific NAT64 Prefix using a Well-

> > Known Name

> > =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Teemu Savolainen

> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Jouni Korhone=
n

> > =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-behave-nat64-dis=
covery-heuristic-00.txt

> > =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 7

> > =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-05-25

> >

> > =A0 =A0This document describes a method for detecting presence of=
 DNS64 and

> > =A0 =A0for learning IPv6 prefix used for protocol translation on =
an access

> > =A0 =A0network without explicit support from the access network. =
=A0The method

> > =A0 =A0depends on existence of a known IPv4-only domain name. =A0=
The

> > =A0 =A0information learned enables applications and hosts to perf=
orm local

> > =A0 =A0IPv6 address synthesis and on dual-stack accesses avoid tr=
aversal

> > =A0 =A0through NAT64.

> >

> >

> > A URL for this Internet-Draft is:

> > http://www.ietf.org/internet-drafts/draft-ietf-=
behave-nat64-discovery-heuristic-

> > 00.txt

> >

> > Internet-Drafts are also available by anonymous FTP at:

> > ftp://ftp.ietf.or=
g/internet-drafts/

> >

> > This Internet-Draft can be retrieved at:

> > ftp://ftp.ietf.org/internet-drafts/draft-ietf-be=
have-nat64-discovery-heuristic-

> > 00.txt

> > _______________________________________________

> > Behave mailing list

> > Behave@ietf.org

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

> _______________________________________________

> Behave mailing list

> Behave@ietf.org

> https://www.i=
etf.org/mailman/listinfo/behave




--000e0ce0b4ea10768f04a47f893b--

From ajs@anvilwalrusden.com  Mon May 30 10:01:42 2011
Return-Path: 
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 988A7E06BC for ; Mon, 30 May 2011 10:01:42 -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=[AWL=0.000,  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 LjGPMSCWDFz6 for ; Mon, 30 May 2011 10:01:42 -0700 (PDT)
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id DEF1FE06DA for ; Mon, 30 May 2011 10:01:41 -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 EB3DF1ECB41C for ; Mon, 30 May 2011 17:01:39 +0000 (UTC)
Date: Mon, 30 May 2011 13:01:23 -0400
From: Andrew Sullivan 
To: behave@ietf.org
Message-ID: <20110530170123.GA23199@shinkuro.com>
References: <916CE6CF87173740BC8A2CE44309696205EE34@008-AM1MPN1-036.mgdnok.nokia.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
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: Mon, 30 May 2011 17:01:42 -0000

On Mon, May 30, 2011 at 07:59:34AM -0700, Cameron Byrne wrote:
> I don't think this will be an impact, but I would like to caution that many
> service providers sends redirects to ad pages and do not send NXDOMAIN to
> customers.  My cable company does this. As worded, this should not be an
> impact, I just want to avoid people writing code here that depend on seeing
> NXDOMAIN that will never come.

Service providers who are doing this are doing all sorts of other dumb
things too.  This heuristic is not going to work reliably (for
instance, it is all but guaranteed to give you the wrong answer in
most hotel networks).  That's part of why I think it's a bad idea:
people have been abusing the DNS for a long time, and so registering
something global like this is in effect depending on conditions that
do not actually obtain all the time.

Nevertheless, we were assured at the mic in Prague that people are
going to implement this sort of probing anyway, not because it's the
most robust nor the best idea but because it was what they know how to
do immediately.  From my point of view, that means that we should
document one way to do such probing so that everyone probes for the
same name; that is less awful only because at least we get some
benefit from caches and so on.  That doesn't mean we should try to
work around all the stupid DNS tricks anyone has ever invented, in a
doomed effort to make this probing (and the entire NAT64/DNS64
mostly-works hack) completely reliable.

A



-- 
Andrew Sullivan
ajs@crankycanuck.ca

From teemu.savolainen@nokia.com  Mon May 30 10:18:33 2011
Return-Path: 
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34DDDE06D9 for ; Mon, 30 May 2011 10:18:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.798
X-Spam-Level: 
X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id asgZXNBnGric for ; Mon, 30 May 2011 10:18:31 -0700 (PDT)
Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 7E726E06BC for ; Mon, 30 May 2011 10:18:31 -0700 (PDT)
Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p4UHIT4F002169; Mon, 30 May 2011 20:18:29 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 30 May 2011 20:18:29 +0300
Received: from 008-AM1MMR1-002.mgdnok.nokia.com (65.54.30.57) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 30 May 2011 19:18:28 +0200
Received: from 008-AM1MPN1-036.mgdnok.nokia.com ([169.254.6.209]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0289.008; Mon, 30 May 2011 19:18:28 +0200
From: 
To: 
Thread-Topic: [BEHAVE] Next for draft-ietf-behave-nat64-discovery-heuristic-00.txt
Thread-Index: Acwevpw8zf4ZcYbGSIma0tKrdgjVhgACs/8AAAkKxkU=
Date: Mon, 30 May 2011 17:18:28 +0000
Message-ID: <916CE6CF87173740BC8A2CE44309696205F17B@008-AM1MPN1-036.mgdnok.nokia.com>
References: <916CE6CF87173740BC8A2CE44309696205EE34@008-AM1MPN1-036.mgdnok.nokia.com>, 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_916CE6CF87173740BC8A2CE44309696205F17B008AM1MPN1036mgdn_"
MIME-Version: 1.0
X-OriginalArrivalTime: 30 May 2011 17:18:29.0508 (UTC) FILETIME=[981DE440:01CC1EED]
X-Nokia-AV: Clean
Cc: behave@ietf.org
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: Mon, 30 May 2011 17:18:33 -0000

--_000_916CE6CF87173740BC8A2CE44309696205F17B008AM1MPN1036mgdn_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

True. So apps should not assume NXDOMAIN, but sending one could be possible=
 action for DNS servers.

In the ad redirect case the well-known IPv4 address is unlikely inside the =
returned ad server's IPv6 address (though could, in which case connectivity=
 test would help).

Will write something about this.

Sent from my Windows Phone

________________________________
From: ext Cameron Byrne
Sent: 30 May 2011 17:59
To: Savolainen Teemu (Nokia-CTO/Tampere)
Cc: behave@ietf.org
Subject: Re: [BEHAVE] Next for draft-ietf-behave-nat64-discovery-heuristic-=
00.txt


On May 30, 2011 4:56 AM, > wrote:
>
> Hi,
>
> The -00 revision was uploaded pretty much as is. I'm looking forward to n=
ext updates to the draft, and I thought those might be as follows:
>
> 1) Clarify that the well-known FQDN is to be specified and hosted by IANA
>
> 2) Ask for a dedicated non-routable IPv4 address for the well-known FQDN
>
> 3) Define long TTL for the well-known name entry so that it can be cached=
 efficiently
>
> 4) Define that the synthesizing DNS64 must handle AAAA query for the well=
-known FQDN as for any other FQDN that does not have AAAA record (=3Dsynthe=
size response normally). However, A DNS server that does not implement AAAA=
 synthesis (DNS64 function) could directly respond NXDOMAIN for the query i=
nstead of forwarding the (in that case pointless) query towards root?
>

I don't think this will be an impact, but I would like to caution that many=
 service providers sends redirects to ad pages and do not send NXDOMAIN to =
customers.  My cable company does this. As worded, this should not be an im=
pact, I just want to avoid people writing code here that depend on seeing N=
XDOMAIN that will never come.

Cb

> 5) Possibly connectivity test conducted after synthesis is to be made to =
applications' own servers, if required.
>
> 6) The name shall be queried again when the lifetime of previous response=
 expires (as was set by DNS64) or if interface changes.
>
> Feedback welcome, as always. I plan to make an updated version by mid-Jun=
e latest.
>
> Best regards,
>
>        Teemu
>
>
> > -----Original Message-----
> > From: behave-bounces@ietf.org [mailto:b=
ehave-bounces@ietf.org] On Behalf
> > Of ext internet-drafts@ietf.org
> > Sent: 25. toukokuuta 2011 20:54
> > To: i-d-announce@ietf.org
> > Cc: behave@ietf.org
> > Subject: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heurist=
ic-00.txt
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts dire=
ctories.
> > This draft is a work item of the Behavior Engineering for Hindrance Avo=
idance
> > Working Group of the IETF.
> >
> >       Title           : Discovery of a Network-Specific NAT64 Prefix us=
ing a Well-
> > Known Name
> >       Author(s)       : Teemu Savolainen
> >                           Jouni Korhonen
> >       Filename        : draft-ietf-behave-nat64-discovery-heuristic-00.=
txt
> >       Pages           : 7
> >       Date            : 2011-05-25
> >
> >    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 metho=
d
> >    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-h=
euristic-
> > 00.txt
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > This Internet-Draft can be retrieved at:
> > ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-nat64-discovery-he=
uristic-
> > 00.txt
> > _______________________________________________
> > Behave mailing list
> > Behave@ietf.org
> > https://www.ietf.org/mailman/listinfo/behave
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave

--_000_916CE6CF87173740BC8A2CE44309696205F17B008AM1MPN1036mgdn_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable







True. So apps=
 should not assume NXDOMAIN, but sending one could be possible action for D=
NS servers.



In the ad redirect case the well-known IPv4 address is unlikely inside the =
returned ad server's IPv6 address (though could, in which case connectivity=
 test would help).



Will write something about this.



Sent from my Windows Phone







From:
ext Ca=
meron Byrne

Sent:
30 May=
 2011 17:59

To:
Savola=
inen Teemu (Nokia-CTO/Tampere)

Cc:
behave=
@ietf.org

Subject:
Re: [B=
EHAVE] Next for draft-ietf-behave-nat64-discovery-heuristic-00.txt







On May 30, 2011 4:56 AM, <=
teemu.savolainen@nokia.com> wrote:

>

> Hi,

>

> The -00 revision was uploaded pretty much as is. I'm looking forward t=
o next updates to the draft, and I thought those might be as follows:

>

> 1) Clarify that the well-known FQDN is to be specified and hosted by I=
ANA

>

> 2) Ask for a dedicated non-routable IPv4 address for the well-known FQ=
DN

>

> 3) Define long TTL for the well-known name entry so that it can be cac=
hed efficiently

>

> 4) Define that the synthesizing DNS64 must handle AAAA query for the w=
ell-known FQDN as for any other FQDN that does not have AAAA record (=3Dsyn=
thesize response normally). However, A DNS server that does not implement A=
AAA synthesis (DNS64 function) could
 directly respond NXDOMAIN for the query instead of forwarding the (in that=
 case pointless) query towards root?

>


I don't think this will be an impact, but I would like to caution that m=
any service providers sends redirects to ad pages and do not send NXDOMAIN =
to customers.  My cable company does this. As worded, this should not =
be an impact, I just want to avoid people
 writing code here that depend on seeing NXDOMAIN that will never come.




Cb




> 5) Possibly connectivity test conducted after synthesis is to be ma=
de to applications' own servers, if required.

>

> 6) The name shall be queried again when the lifetime of previous respo=
nse expires (as was set by DNS64) or if interface changes.

>

> Feedback welcome, as always. I plan to make an updated version by mid-=
June latest.

>

> Best regards,

>

>        Teemu

>

>

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

> > From: behave-bounces@i=
etf.org [mailto:behave-bounc=
es@ietf.org] On Behalf

> > Of ext internet-draft=
s@ietf.org

> > Sent: 25. toukokuuta 2011 20:54

> > To: i-d-announce@ietf.or=
g

> > Cc: behave@ietf.org

> > Subject: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-h=
euristic-00.txt

> >

> > A New Internet-Draft is available from the on-line Internet-Draft=
s directories.

> > This draft is a work item of the Behavior Engineering for Hindran=
ce Avoidance

> > Working Group of the IETF.

> >

> >       Title           : D=
iscovery of a Network-Specific NAT64 Prefix using a Well-

> > Known Name

> >       Author(s)       : Teemu Savol=
ainen

> >                   &n=
bsp;       Jouni Korhonen

> >       Filename        : draft-=
ietf-behave-nat64-discovery-heuristic-00.txt

> >       Pages           : 7=


> >       Date           &nbs=
p;: 2011-05-25

> >

> >    This document describes a method for detecting prese=
nce of DNS64 and

> >    for learning IPv6 prefix used for protocol translati=
on on an access

> >    network without explicit support from the access net=
work.  The method

> >    depends on existence of a known IPv4-only domain nam=
e.  The

> >    information learned enables applications and hosts t=
o perform local

> >    IPv6 address synthesis and on dual-stack accesses av=
oid traversal

> >    through NAT64.

> >

> >

> > A URL for this Internet-Draft is:

> > 
http://www.ietf.org/internet-drafts/draft-ietf-behave-nat64-discovery-heuri=
stic-

> > 00.txt

> >

> > Internet-Drafts are also available by anonymous FTP at:

> > ftp://ftp.ietf.or=
g/internet-drafts/

> >

> > This Internet-Draft can be retrieved at:

> > 
ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-nat64-discovery-heuris=
tic-

> > 00.txt

> > _______________________________________________

> > Behave mailing list

> > Behave@ietf.org

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

> _______________________________________________

> Behave mailing list

> Behave@ietf.org

> https://www.i=
etf.org/mailman/listinfo/behave








--_000_916CE6CF87173740BC8A2CE44309696205F17B008AM1MPN1036mgdn_--

From cb.list6@gmail.com  Mon May 30 10:32:54 2011
Return-Path: 
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 540A1E070B for ; Mon, 30 May 2011 10:32:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.448
X-Spam-Level: 
X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.150,  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 cY7ODI9AiIm8 for ; Mon, 30 May 2011 10:32:53 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id ECA03E06BC for ; Mon, 30 May 2011 10:32:52 -0700 (PDT)
Received: by wwa36 with SMTP id 36so2819187wwa.13 for ; Mon, 30 May 2011 10:32:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=TmSsSfJ1UUX1ciAQGs/eH1O5KHfZnC/CI62uO6owync=; b=mIj1R8FoZYNU/z51SXMHqDG4Snm0xl0spMyBPzDXjWCMny/ezfMfrx7BSnVxtrCxR1 qczhICJeachW8c6z5Xd/Cy5LY96KSt7bWIOxX5AvMKafUyJ4RH9ElEvYtrqsImZrOlqW CwuzzOlW2RwilaTF3dwqlCg0wnFOU37APNxEw=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=TMknGbIWdy9j7YpgTh1bxpHx1BHldRIvGYuYRO3jrcV48tUPg0g7vKXAx/i/SskoS+ YQK/uTQMEWt0+btLu2h9CTmHEt7fUipD7vg/4IWn8vY7w/dwXjUZxqqMl7hqDxoBiaT4 OlX1RK8ul0ouZJEUtRcZ4Pjanf0QGnenG2PMw=
MIME-Version: 1.0
Received: by 10.216.241.132 with SMTP id g4mr2290632wer.9.1306776771821; Mon, 30 May 2011 10:32:51 -0700 (PDT)
Received: by 10.216.179.199 with HTTP; Mon, 30 May 2011 10:32:51 -0700 (PDT)
Received: by 10.216.179.199 with HTTP; Mon, 30 May 2011 10:32:51 -0700 (PDT)
In-Reply-To: <916CE6CF87173740BC8A2CE44309696205F17B@008-AM1MPN1-036.mgdnok.nokia.com>
References: <916CE6CF87173740BC8A2CE44309696205EE34@008-AM1MPN1-036.mgdnok.nokia.com>  <916CE6CF87173740BC8A2CE44309696205F17B@008-AM1MPN1-036.mgdnok.nokia.com>
Date: Mon, 30 May 2011 10:32:51 -0700
Message-ID: 
From: Cameron Byrne 
To: teemu.savolainen@nokia.com
Content-Type: multipart/alternative; boundary=e0cb4e43d1b94902bf04a481aded
Cc: behave@ietf.org
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: Mon, 30 May 2011 17:32:54 -0000

--e0cb4e43d1b94902bf04a481aded
Content-Type: text/plain; charset=ISO-8859-1

On May 30, 2011 10:18 AM,  wrote:
>
> True. So apps should not assume NXDOMAIN, but sending one could be
possible action for DNS servers.
>
> In the ad redirect case the well-known IPv4 address is unlikely inside the
returned ad server's IPv6 address (though could, in which case connectivity
test would help).
>
> Will write something about this.
>
As fyi,

I would assume the ad server is possibly native ipv6 and therefore would not
have any info to gleen from. If an sp has nat64 they like drive their own
infrastructure to be native v6, especially revenue generation ads.

Cb

>
> Sent from my Windows Phone
>
> ________________________________
> From: ext Cameron Byrne
> Sent: 30 May 2011 17:59
>
> To: Savolainen Teemu (Nokia-CTO/Tampere)
> Cc: behave@ietf.org
> Subject: Re: [BEHAVE] Next for
draft-ietf-behave-nat64-discovery-heuristic-00.txt
>
>
>
> On May 30, 2011 4:56 AM,  wrote:
> >
> > Hi,
> >
> > The -00 revision was uploaded pretty much as is. I'm looking forward to
next updates to the draft, and I thought those might be as follows:
> >
> > 1) Clarify that the well-known FQDN is to be specified and hosted by
IANA
> >
> > 2) Ask for a dedicated non-routable IPv4 address for the well-known FQDN
> >
> > 3) Define long TTL for the well-known name entry so that it can be
cached efficiently
> >
> > 4) Define that the synthesizing DNS64 must handle AAAA query for the
well-known FQDN as for any other FQDN that does not have AAAA record
(=synthesize response normally). However, A DNS server that does not
implement AAAA synthesis (DNS64 function) could directly respond NXDOMAIN
for the query instead of forwarding the (in that case pointless) query
towards root?
> >
>
> I don't think this will be an impact, but I would like to caution that
many service providers sends redirects to ad pages and do not send NXDOMAIN
to customers.  My cable company does this. As worded, this should not be an
impact, I just want to avoid people writing code here that depend on seeing
NXDOMAIN that will never come.
>
> Cb
>
> > 5) Possibly connectivity test conducted after synthesis is to be made to
applications' own servers, if required.
> >
> > 6) The name shall be queried again when the lifetime of previous
response expires (as was set by DNS64) or if interface changes.
> >
> > Feedback welcome, as always. I plan to make an updated version by
mid-June latest.
> >
> > Best regards,
> >
> >        Teemu
> >
> >
> > > -----Original Message-----
> > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On
Behalf
> > > Of ext internet-drafts@ietf.org
> > > Sent: 25. toukokuuta 2011 20:54
> > > To: i-d-announce@ietf.org
> > > Cc: behave@ietf.org
> > > Subject: [BEHAVE] I-D Action:
draft-ietf-behave-nat64-discovery-heuristic-00.txt
> > >
> > > 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           : Discovery of a Network-Specific NAT64 Prefix
using a Well-
> > > Known Name
> > >       Author(s)       : Teemu Savolainen
> > >                           Jouni Korhonen
> > >       Filename        :
draft-ietf-behave-nat64-discovery-heuristic-00.txt
> > >       Pages           : 7
> > >       Date            : 2011-05-25
> > >
> > >    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-heuristic-
> > > 00.txt
> > >
> > > Internet-Drafts are also available by anonymous FTP at:
> > > ftp://ftp.ietf.org/internet-drafts/
> > >
> > > This Internet-Draft can be retrieved at:
> > >
ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-nat64-discovery-heuristic-
> > > 00.txt
> > > _______________________________________________
> > > Behave mailing list
> > > Behave@ietf.org
> > > https://www.ietf.org/mailman/listinfo/behave
> > _______________________________________________
> > Behave mailing list
> > Behave@ietf.org
> > https://www.ietf.org/mailman/listinfo/behave

--e0cb4e43d1b94902bf04a481aded
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable




On May 30, 2011 10:18 AM, <teemu.savolainen@nokia.com> wrote:

>

> True. So apps should not assume NXDOMAIN, but sending one could be pos=
sible action for DNS servers.

>

> In the ad redirect case the well-known IPv4 address is unlikely inside=
 the returned ad server's IPv6 address (though could, in which case con=
nectivity test would help).

>

> Will write something about this.

>

As fyi,


I would assume the ad server is possibly native ipv6 and therefore would=
 not have any info to gleen from. If an sp has nat64 they like drive their =
own infrastructure to be native v6, especially revenue generation ads. 



Cb


>

> Sent from my Windows Phone

>

> ________________________________

> From: ext Cameron Byrne

> Sent: 30 May 2011 17:59

>

> To: Savolainen Teemu (Nokia-CTO/Tampere)

> Cc: behave@ietf.org

> Subject: Re: [BEHAVE] Next for draft-ietf-behave-nat64-discovery-heuri=
stic-00.txt

>

>

>

> On May 30, 2011 4:56 AM, <teemu.savolainen@nokia.com> wrote:

> >

> > Hi,

> >

> > The -00 revision was uploaded pretty much as is. I'm looking =
forward to next updates to the draft, and I thought those might be as follo=
ws:

> >

> > 1) Clarify that the well-known FQDN is to be specified and hosted=
 by IANA

> >

> > 2) Ask for a dedicated non-routable IPv4 address for the well-kno=
wn FQDN

> >

> > 3) Define long TTL for the well-known name entry so that it can b=
e cached efficiently

> >

> > 4) Define that the synthesizing DNS64 must handle AAAA query for =
the well-known FQDN as for any other FQDN that does not have AAAA record (=
=3Dsynthesize response normally). However, A DNS server that does not imple=
ment AAAA synthesis (DNS64 function) could directly respond NXDOMAIN for th=
e query instead of forwarding the (in that case pointless) query towards ro=
ot?


> >

>

> I don't think this will be an impact, but I would like to caution =
that many service providers sends redirects to ad pages and do not send NXD=
OMAIN to customers.=A0 My cable company does this. As worded, this should n=
ot be an impact, I just want to avoid people writing code here that depend =
on seeing NXDOMAIN that will never come.


>

> Cb

>

> > 5) Possibly connectivity test conducted after synthesis is to be =
made to applications' own servers, if required.

> >

> > 6) The name shall be queried again when the lifetime of previous =
response expires (as was set by DNS64) or if interface changes.

> >

> > Feedback welcome, as always. I plan to make an updated version by=
 mid-June latest.

> >

> > Best regards,

> >

> > =A0 =A0 =A0 =A0Teemu

> >

> >

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

> > > From: behave-boun=
ces@ietf.org [mailto:behave-=
bounces@ietf.org] On Behalf

> > > Of ext internet-=
drafts@ietf.org

> > > Sent: 25. toukokuuta 2011 20:54

> > > To: i-d-announce@ie=
tf.org

> > > Cc: behave@ietf.org
> > > Subject: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discov=
ery-heuristic-00.txt

> > >

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

> > > This draft is a work item of the Behavior Engineering for Hi=
ndrance Avoidance

> > > Working Group of the IETF.

> > >

> > > =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Discovery of a Netwo=
rk-Specific NAT64 Prefix using a Well-

> > > Known Name

> > > =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Teemu Savolainen

> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Jouni Ko=
rhonen

> > > =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-behave-nat6=
4-discovery-heuristic-00.txt

> > > =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 7

> > > =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-05-25

> > >

> > > =A0 =A0This document describes a method for detecting presen=
ce of DNS64 and

> > > =A0 =A0for learning IPv6 prefix used for protocol translatio=
n on an access

> > > =A0 =A0network without explicit support from the access netw=
ork. =A0The method

> > > =A0 =A0depends on existence of a known IPv4-only domain name=
. =A0The

> > > =A0 =A0information learned enables applications and hosts to=
 perform local

> > > =A0 =A0IPv6 address synthesis and on dual-stack accesses avo=
id traversal

> > > =A0 =A0through NAT64.

> > >

> > >

> > > A URL for this Internet-Draft is:

> > > http://www.ietf.org/internet-drafts/draft-=
ietf-behave-nat64-discovery-heuristic-

> > > 00.txt

> > >

> > > Internet-Drafts are also available by anonymous FTP at:

> > > ftp://ftp.ie=
tf.org/internet-drafts/

> > >

> > > This Internet-Draft can be retrieved at:

> > > ftp://ftp.ietf.org/internet-drafts/draft-ie=
tf-behave-nat64-discovery-heuristic-

> > > 00.txt

> > > _______________________________________________

> > > Behave mailing list

> > > Behave@ietf.org

> > > htt=
ps://www.ietf.org/mailman/listinfo/behave

> > _______________________________________________

> > Behave mailing list

> > Behave@ietf.org

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




--e0cb4e43d1b94902bf04a481aded--

From huitema@microsoft.com  Mon May 30 12:52:05 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 08F8EE06AB for ; Mon, 30 May 2011 12:52:05 -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 MBFv2xihgFhp for ; Mon, 30 May 2011 12:52:02 -0700 (PDT)
Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id C7B02E067F for ; Mon, 30 May 2011 12:52:02 -0700 (PDT)
Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 30 May 2011 12:52:02 -0700
Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) with Microsoft SMTP Server (TLS) id 14.1.289.8; Mon, 30 May 2011 12:52:02 -0700
Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.58]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0289.008; Mon, 30 May 2011 12:52:02 -0700
From: Christian Huitema 
To: "teemu.savolainen@nokia.com" , "behave@ietf.org" 
Thread-Topic: Next for draft-ietf-behave-nat64-discovery-heuristic-00.txt
Thread-Index: Acwevpw8zf4ZcYbGSIma0tKrdgjVhgAQtsCQ
Date: Mon, 30 May 2011 19:52:00 +0000
Message-ID: <22F6318E46E26B498ABC828879B08D4F15E1D3@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com>
References: <916CE6CF87173740BC8A2CE44309696205EE34@008-AM1MPN1-036.mgdnok.nokia.com>
In-Reply-To: <916CE6CF87173740BC8A2CE44309696205EE34@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: [157.54.51.43]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Mon, 30 May 2011 19:52:05 -0000

> 1) Clarify that the well-known FQDN is to be specified and hosted by IANA

Can you estimate how much traffic that will generate to the IANA internet s=
ervers? Each transaction may be small, but if every host on the Internet do=
es resolve this name each time they get powered up or move to a new network=
, we may be facing some large traffic. Do we have estimates on the efficien=
cy of DNS caching? Is someone measuring that, maybe CAIDA?

> 2) Ask for a dedicated non-routable IPv4 address for the well-known FQDN

The examples there are problematic -- they belong to reserved range 127.0.0=
.0/8 (local host) and 192.168.0.0/16 (RFC 1918). There two issues:

 - IANA does not control allocation in these ranges, which means it cannot =
guarantee that they are not somehow reachable in the local environment;
- RFC 6052 specifically states that " The Well-Known Prefix MUST NOT be use=
d to represent non-global IPv4 addresses, such as those defined in [RFC1918=
] or listed in Section 3 of [RFC5735]," which means that the proposed algor=
ithm will never be able to detect use of the WKP.

>From an operational point of view, it may be better to make the FQDN and ad=
dresses configurable. I can see for example how these could be configured s=
imultaneously with STUN/TURN servers.

-- Christian Huitema






From ajs@anvilwalrusden.com  Mon May 30 13:41:53 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 A5FA5E06CF for ; Mon, 30 May 2011 13:41:53 -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 YmUw-66qicc2 for ; Mon, 30 May 2011 13:41:53 -0700 (PDT)
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 761C4E067F for ; Mon, 30 May 2011 13:41:53 -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 45B721ECB41C for ; Mon, 30 May 2011 20:41:52 +0000 (UTC)
Date: Mon, 30 May 2011 16:41:51 -0400
From: Andrew Sullivan 
To: behave@ietf.org
Message-ID: <20110530204151.GD23199@shinkuro.com>
References: <916CE6CF87173740BC8A2CE44309696205EE34@008-AM1MPN1-036.mgdnok.nokia.com> <22F6318E46E26B498ABC828879B08D4F15E1D3@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <22F6318E46E26B498ABC828879B08D4F15E1D3@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.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: Mon, 30 May 2011 20:41:53 -0000

On Mon, May 30, 2011 at 07:52:00PM +0000, Christian Huitema wrote:
> > 1) Clarify that the well-known FQDN is to be specified and hosted by IANA
> 
> Can you estimate how much traffic that will generate to the IANA internet servers? Each transaction may be small, but if every host on the Internet does resolve this name each time they get powered up or move to a new network, we may be facing some large traffic. Do we have estimates on the efficiency of DNS caching? Is someone measuring that, maybe CAIDA?
> 

The closest measurement you'd likely get is from the AS112 project.
We might look at the DITL data or something like that.
https://www.dns-oarc.net/oarc/data/ditl.

But yes, this is a fairly large data load.

> >From an operational point of view, it may be better to make the FQDN and addresses configurable. I can see for example how these could be configured simultaneously with STUN/TURN servers.
> 

This would be much worse from the POV of caches: if everyone is always
asking for the same thing, then the NS set for that domain is mostly
cached in recursive resolvers.  If people ask all sorts of different
things, then they're all effectively just brand new lookups.

Moreover, the only reason for this WG to do anything at all in this
area is to get everyone to use the same name when doing this lookup.
If everyone is going to do their own thing, why standardize anything
at all? 

A

-- 
Andrew Sullivan
ajs@crankycanuck.ca

From teemu.savolainen@nokia.com  Mon May 30 15:01: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 904C5E0737 for ; Mon, 30 May 2011 15:01:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.766
X-Spam-Level: 
X-Spam-Status: No, score=-2.766 tagged_above=-999 required=5 tests=[AWL=-0.166, 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 Tuuk3lj0XHUD for ; Mon, 30 May 2011 15:01:11 -0700 (PDT)
Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 7C687E0731 for ; Mon, 30 May 2011 15:01:11 -0700 (PDT)
Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p4UM1AVF030242; Tue, 31 May 2011 01:01:10 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 31 May 2011 01:01:05 +0300
Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 31 May 2011 00:01:04 +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; Tue, 31 May 2011 00:01:04 +0200
From: 
To: , 
Thread-Topic: Next for draft-ietf-behave-nat64-discovery-heuristic-00.txt
Thread-Index: Acwevpw8zf4ZcYbGSIma0tKrdgjVhgAQtsCQAAI/btA=
Date: Mon, 30 May 2011 22:01:04 +0000
Message-ID: <916CE6CF87173740BC8A2CE44309696205F2D0@008-AM1MPN1-036.mgdnok.nokia.com>
References: <916CE6CF87173740BC8A2CE44309696205EE34@008-AM1MPN1-036.mgdnok.nokia.com> <22F6318E46E26B498ABC828879B08D4F15E1D3@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com>
In-Reply-To: <22F6318E46E26B498ABC828879B08D4F15E1D3@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.162.63.227]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 30 May 2011 22:01:05.0568 (UTC) FILETIME=[12B75200:01CC1F15]
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: Mon, 30 May 2011 22:01:12 -0000

> > 1) Clarify that the well-known FQDN is to be specified and hosted by IA=
NA
>=20
> Can you estimate how much traffic that will generate to the IANA internet
> servers? Each transaction may be small, but if every host on the Internet=
 does
> resolve this name each time they get powered up or move to a new network,
> we may be facing some large traffic. Do we have estimates on the efficien=
cy of
> DNS caching? Is someone measuring that, maybe CAIDA?

Unfortunately I do not have such data, but Andrew seemed to have something.

Related to this I was asking couple of emails back if the prefix discovery =
should be performed only on-demand, i.e. if an application requires the inf=
ormation or e.g. if a host happens to implement DNSSEC recursive resolver -=
 which I guess could be considered as an "application" as well in this rega=
rd (this btw relates to earlier email from Michael Richardson we did not ye=
t reply - will reply later - why recursive resolver couldn't send one recur=
sive query to find out the prefix?).=20

> > 2) Ask for a dedicated non-routable IPv4 address for the well-known FQD=
N
>=20
> The examples there are problematic -- they belong to reserved range
> 127.0.0.0/8 (local host) and 192.168.0.0/16 (RFC 1918). There two issues:
>=20
>  - IANA does not control allocation in these ranges, which means it canno=
t
> guarantee that they are not somehow reachable in the local environment;
> - RFC 6052 specifically states that " The Well-Known Prefix MUST NOT be u=
sed
> to represent non-global IPv4 addresses, such as those defined in [RFC1918=
] or
> listed in Section 3 of [RFC5735]," which means that the proposed algorith=
m will
> never be able to detect use of the WKP.

I had missed that part of RFC6052. Good point.

How bad thing is that actually?=20

Let's say that in an IPv6-only access network an application has IPv4 liter=
al at hand. Application does NSP discovery for a well-known name having let=
's say RFC5736 address. However, the access network happens to be using WKP=
, in which case probably an empty AAAA response is returned. As the applica=
tion still does not have IPv4 access, and no NSP is in use, application sho=
uld perhaps just make a connectivity attempt/test by using WKP on synthesis=
? If WKP based address does not work out either, then host is on strictly I=
Pv6-only access.=20

In the dual-stack case an application may receive IPv6 address (from DNS) a=
nd it needs to know whether the address is synthetic or not (e.g. whether t=
o prefer native IPv4 instead of IPv6 (say application has serious NAT64 tra=
versal issues)), and if the application does not immediately spot WKP in th=
e IPv6 address it received, it can check if the network happens to utilize =
NSP by doing a query to the well-known name. If no WKP, and no NSP, applica=
tion should have a real IPv6 address.

Or would you recommend using a global IPv4 address instead to simplify logi=
c? Personally I was afraid that it would attract unwanted traffic to select=
ed address and I'm not sure if that is ok?

Best regards,

	Teemu


From huitema@microsoft.com  Tue May 31 12:47: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 C209CE06D9 for ; Tue, 31 May 2011 12:47:16 -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 rTsgdyEoHQ8o for ; Tue, 31 May 2011 12:47:16 -0700 (PDT)
Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 42E72E06A8 for ; Tue, 31 May 2011 12:47:16 -0700 (PDT)
Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 31 May 2011 12:47:15 -0700
Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) with Microsoft SMTP Server (TLS) id 14.1.289.8; Tue, 31 May 2011 12:47:15 -0700
Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.58]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.01.0289.008; Tue, 31 May 2011 12:47:15 -0700
From: Christian Huitema 
To: "teemu.savolainen@nokia.com" , "behave@ietf.org" 
Thread-Topic: Next for draft-ietf-behave-nat64-discovery-heuristic-00.txt
Thread-Index: Acwevpw8zf4ZcYbGSIma0tKrdgjVhgAQtsCQAAI/btAAKz+OoA==
Date: Tue, 31 May 2011 19:47:14 +0000
Message-ID: <22F6318E46E26B498ABC828879B08D4F15ECE0@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com>
References: <916CE6CF87173740BC8A2CE44309696205EE34@008-AM1MPN1-036.mgdnok.nokia.com> <22F6318E46E26B498ABC828879B08D4F15E1D3@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> <916CE6CF87173740BC8A2CE44309696205F2D0@008-AM1MPN1-036.mgdnok.nokia.com>
In-Reply-To: <916CE6CF87173740BC8A2CE44309696205F2D0@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: [157.54.51.90]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Tue, 31 May 2011 19:47:16 -0000

> How bad thing is that actually?=20

I would expect implementers of NPT to check the validity of addresses. If t=
hey don't, they make the networks vulnerable to all kinds of interesting at=
tacks. So I expect that if a DNS record returns "invalid" addresses, these =
addresses will not be mapped. That means the very idea of "well known inval=
id address" is probably problematic.

> Or would you recommend using a global IPv4 address instead to simplify lo=
gic? Personally I was afraid that it would attract unwanted traffic to sele=
cted address and I'm not sure if that is ok?

I would recommend doing away with the idea of "well known FQDN and addresse=
s" and make that a configuration parameter.

-- Christian Huitema



From ajs@anvilwalrusden.com  Tue May 31 13:18:10 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 2E2CFE0679 for ; Tue, 31 May 2011 13:18:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.474
X-Spam-Level: 
X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125,  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 iNHR2oCcg35x for ; Tue, 31 May 2011 13:18:09 -0700 (PDT)
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id A0174E0675 for ; Tue, 31 May 2011 13:18:09 -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 1BE311ECB41F for ; Tue, 31 May 2011 20:18:08 +0000 (UTC)
Date: Tue, 31 May 2011 16:18:01 -0400
From: Andrew Sullivan 
To: behave@ietf.org
Message-ID: <20110531201801.GA26780@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <22F6318E46E26B498ABC828879B08D4F15ECE0@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.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: Tue, 31 May 2011 20:18:10 -0000

On Tue, May 31, 2011 at 07:47:14PM +0000, Christian Huitema wrote:
> 
> I would recommend doing away with the idea of "well known FQDN and addresses" and make that a configuration parameter.
> 

The lookup _has to_ be a well-known name in order for this filthy hack
to be any use at all.  Either it will be one well-known name per
application (for everyone in the world using that application), or it
will be one well-known name that everyone shares.  The cache
implications are obviously in favour of the latter.

The reason it needs to be a well-known name is because otherwise,
you'd need to have some other way of learning the name you need to
query.  But if there were some mechanism by which you could learn this
name, we wouldn't need to have the name in the first place, because we
could just tell you, "Dude, you're behind a NAT64," and all would be
right with the world.

So, a configuration parameter does not help.

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com


From huitema@microsoft.com  Tue May 31 14:36: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 8A74CE08D2 for ; Tue, 31 May 2011 14:36:37 -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 YxpoZginZGMq for ; Tue, 31 May 2011 14:36:37 -0700 (PDT)
Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0F9E08D1 for ; Tue, 31 May 2011 14:36:37 -0700 (PDT)
Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 31 May 2011 14:36:36 -0700
Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) with Microsoft SMTP Server (TLS) id 14.1.289.8; Tue, 31 May 2011 14:36:36 -0700
Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.58]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0289.008; Tue, 31 May 2011 14:36:36 -0700
From: Christian Huitema 
To: Andrew Sullivan , "behave@ietf.org" 
Thread-Topic: [BEHAVE] Next for draft-ietf-behave-nat64-discovery-heuristic-00.txt
Thread-Index: Acwevpw8zf4ZcYbGSIma0tKrdgjVhgAQtsCQAAI/btAAKz+OoAAUxAKAAAxIx5A=
Date: Tue, 31 May 2011 21:36:35 +0000
Message-ID: <22F6318E46E26B498ABC828879B08D4F15F12F@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.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>
In-Reply-To: <20110531201801.GA26780@shinkuro.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.90]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Tue, 31 May 2011 21:36:37 -0000

> The reason it needs to be a well-known name is because otherwise, you'd n=
eed to have some other way of learning the=20
> name you need to query.  But if there were some mechanism by which you co=
uld learn this name, we wouldn't need to=20
> have the name in the first place, because we could just tell you, "Dude, =
you're behind a NAT64," and all would be right=20
> with the world.

I am clearly not looking at something configured via DHCP. There are plenty=
 of configuration parameters that are not dependent on the local network. F=
or 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 ai=
rport. Similarly, my SIP client is configured with the domain name of the S=
TUN/TURN server that is uses for NAT traversal. The same SIP client could a=
ctually easily be configured with the name of the "NAT 64 discovery server.=
"

-- Christian Huitema




From cb.list6@gmail.com  Tue May 31 14:37:54 2011
Return-Path: 
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEA86E0728 for ; Tue, 31 May 2011 14:37:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.498
X-Spam-Level: 
X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=0.101,  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 RWfy8gafJ6oi for ; Tue, 31 May 2011 14:37:54 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2BDF9E067B for ; Tue, 31 May 2011 14:37:53 -0700 (PDT)
Received: by wwa36 with SMTP id 36so3713743wwa.13 for ; Tue, 31 May 2011 14:37:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Z3fTE/HXVbOpq16dVqox/2cNhMnovNmQ+N+7uia3laQ=; b=lKUCAj79yCcVqGDpFZ/+mwdUntLN0KH6/OYViVdkrn2ZYOCemb+jlPt1Q/YY5vZEAE bTZfcYVRMq1xoN7nhioaflj/LLYP+Fu75OM6g5N7E5Djh1C4zY4rcybBuzZKc5nl6ZvA kydM2Chh39ephhZ0F5ewOkEMPWqVEjz6C9RyY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Y9EN02sKkoz6QmdRPy+2b2vIfuza7BB0vZnXdxULmNZLUDIpN+qNBBCXtP15kk5wf/ 2fLCCKqTZrolGoXvsnpiEWYdTZk1do+pEYFySNtlNoOvfugl6uHTVTK44/xCJvl0ehj8 5LWVTmFwF1ux5kf4ABXnLgEb9A13IwQ7CaEpA=
MIME-Version: 1.0
Received: by 10.216.255.206 with SMTP id j56mr2896738wes.39.1306877873111; Tue, 31 May 2011 14:37:53 -0700 (PDT)
Received: by 10.216.179.199 with HTTP; Tue, 31 May 2011 14:37:53 -0700 (PDT)
In-Reply-To: <20110531201801.GA26780@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>
Date: Tue, 31 May 2011 14:37:53 -0700
Message-ID: 
From: Cameron Byrne 
To: Andrew Sullivan 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: behave@ietf.org
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: Tue, 31 May 2011 21:37:55 -0000

On Tue, May 31, 2011 at 1:18 PM, Andrew Sullivan  w=
rote:
> On Tue, May 31, 2011 at 07:47:14PM +0000, Christian Huitema wrote:
>>
>> I would recommend doing away with the idea of "well known FQDN and addre=
sses" and make that a configuration parameter.
>>
>
> The lookup _has to_ be a well-known name in order for this filthy hack
> to be any use at all. =A0Either it will be one well-known name per
> application (for everyone in the world using that application), or it
> will be one well-known name that everyone shares. =A0The cache
> implications are obviously in favour of the latter.
>
> The reason it needs to be a well-known name is because otherwise,
> you'd need to have some other way of learning the name you need to
> query. =A0But if there were some mechanism by which you could learn this
> name, we wouldn't need to have the name in the first place, because we
> could just tell you, "Dude, you're behind a NAT64," and all would be
> right with the world.
>
> So, a configuration parameter does not help.
>

Agreed that well known FQDN is needed and Andrew's logic.

Cameron

> A
>
> --
> Andrew Sullivan
> ajs@anvilwalrusden.com
>
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave
>

From ajs@anvilwalrusden.com  Tue May 31 15:06: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 3CB8FE072C for ; Tue, 31 May 2011 15:06:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.488
X-Spam-Level: 
X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=0.111,  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 36btAnErUMGb for ; Tue, 31 May 2011 15:06:25 -0700 (PDT)
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 84D73E0724 for ; Tue, 31 May 2011 15:06:25 -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 085AA1ECB41F for ; Tue, 31 May 2011 22:06:23 +0000 (UTC)
Date: Tue, 31 May 2011 18:06:22 -0400
From: Andrew Sullivan 
To: behave@ietf.org
Message-ID: <20110531220622.GF26780@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <22F6318E46E26B498ABC828879B08D4F15F12F@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.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: Tue, 31 May 2011 22:06:26 -0000

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

-- 
Andrew Sullivan
ajs@anvilwalrusden.com

From prondou@gmail.com  Tue May 31 16:57:32 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 1C340E07C9; Tue, 31 May 2011 16:57:32 -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 igLJsXQYqR6V; Tue, 31 May 2011 16:57:31 -0700 (PDT)
Received: from mailrelay001.isp.belgacom.be (mailrelay001.isp.belgacom.be [195.238.6.51]) by ietfa.amsl.com (Postfix) with ESMTP id E8D5EE06A0; Tue, 31 May 2011 16:57:30 -0700 (PDT)
X-Belgacom-Dynamic: yes
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApIBAEd+5U1R9wUR/2dsb2JhbAAMRxDcOYZrOYhnhh4EkE+OZTc
Received: from 17.5-247-81.adsl-dyn.isp.belgacom.be (HELO [192.168.1.40]) ([81.247.5.17]) by relay.skynet.be with ESMTP; 01 Jun 2011 01:57:29 +0200
Message-ID: <4DE58062.90207@gmail.com>
Date: Wed, 01 Jun 2011 01:57:22 +0200
From: Pierre Rondou 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11
MIME-Version: 1.0
To: behave@ietf.org, v6ops@ietf.org, netfilter-devel@vger.kernel.org,  evyncke@cisco.com, guy.leduc@ulg.ac.be,  Cyril Soldani 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: [BEHAVE] Netfilter Module for NAT64 available
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, 31 May 2011 23:57:32 -0000

Hello everybody,

I'm currently a student at the University of Liège. As part of my master 
thesis, I have to develop a Linux kernel module for NAT64 ( 
http://datatracker.ietf.org/doc/rfc6146/ ).

I now consider my module as finished (i.e, all functionalities are 
implemented) and publish it.

It is available on sourceforge:

http://sourceforge.net/projects/nat64/

Feel free to test it and report to me any bug, bad implementation, 
error, ...

Like my previous module (http://sourceforge.net/projects/nativi/ , which 
have been updated), it can get included in Xtables/Kernel if you want, 
for now it is limited to 2.6.32 kernel.
I may provide patches for this a bit later.

Documentation is provided in the source code, if you have any question 
don't hesitate to ask me.

Regards,

Pierre RONDOU