From jouni.nospam@gmail.com Tue Oct 4 06:16: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 A4C0421F8CDC for ; Tue, 4 Oct 2011 06:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.497 X-Spam-Level: X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=-0.858, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eT0geunbAqw8 for ; Tue, 4 Oct 2011 06:16:40 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id DEB4921F8CDB for ; Tue, 4 Oct 2011 06:16:35 -0700 (PDT) Received: by bkaq10 with SMTP id q10so852775bka.31 for ; Tue, 04 Oct 2011 06:19:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=x6VXft/0CFz9z3Av1cABkiWoyNlADXABiKHetLCRiR8=; b=u07LzAT+eFb+Fapc0AZJbtig7Ee1dtYMG0dPq+YOvEOZA9t3zy8oDoOqEfjCMagMNa bqyYQAMnYxzBXDjez4lxf1iw0THezvww/hF7/2WhBbzv/RHA+fzCtmrrw8nrQqT/PKj2 14Iex5/8k5pYLPL1EzUALx1YSx3B2Z0yU35og= Received: by 10.204.144.207 with SMTP id a15mr743962bkv.178.1317734378736; Tue, 04 Oct 2011 06:19:38 -0700 (PDT) Received: from a83-245-210-213.elisa-laajakaista.fi (a83-245-210-213.elisa-laajakaista.fi. [83.245.210.213]) by mx.google.com with ESMTPS id z9sm16576217bkn.7.2011.10.04.06.19.36 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 04 Oct 2011 06:19:37 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <4E68828F.5010506@cs.helsinki.fi> Date: Tue, 4 Oct 2011 16:19:35 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <61DF26D4-7AD8-4D67-970B-B677354D3A78@gmail.com> References: <000101cc48b3$a9f87500$fde95f00$@com> <4E68828F.5010506@cs.helsinki.fi> To: Yi DING(Aaron) X-Mailer: Apple Mail (2.1084) Cc: behave@ietf.org, draft-ietf-behave-nat64-learn-analysis@tools.ietf.org, Dan Wing Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-nat64-learn-analysis-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 13:16:40 -0000 Hi Aaron, On Sep 8, 2011, at 11:53 AM, Yi DING(Aaron) wrote: >=20 > Some comments on "draft-ietf-behave-nat64-learn-analysis-00": >=20 > * Issue 1-5 could be emphasized as a separate section / subsection = under Section 3 Right.. however, I rather keep the text in this part as it is now. > * As DNS query for well-known name becomes the recommendation, for = clarity as well as highlight, we should move it up as the first solution = in Section 4. Good point. Will do the change. >=20 >=20 > The document is well-written, concise, and coupled with an extensive = survey of existing mechanisms to learn NAT64 prefix. The comparison = chart is very valuable for networking research as well. I agree with = Cameron that we shall push this document forward. Thanks, Jouni >=20 > -- Aaron >=20 >=20 >=20 > On 06/09/11 23:03, Cameron Byrne wrote: >> On Fri, Jul 22, 2011 at 2:09 PM, Dan Wing wrote: >>> This starts a 3 week WGLC (extra time to accommodate IETF travel) = for >>> draft-ietf-behave-nat64-learn-analysis-00. This document analyzes = the >>> available approaches for a host to learn its NAT64 prefix. = Abstract: >>>=20 >>> Hosts and applications may benefit from the knowledge if an IPv6 >>> address is synthesized, which would mean a NAT64 is used to reach = the >>> IPv4 network or Internet. This document analyses a number of >>> proposed solutions for communicating whether the synthesis is = taking >>> place, used address format, and the IPv6 prefix used by the NAT64 = and >>> DNS64. The solutions enable both NAT64 avoidance and intentional >>> utilization by allowing local IPv6 address synthesis. The = document >>> concludes by recommending selection of heuristic discovery based >>> solution. >>>=20 >>> Please send comments to behave@ietf.org. WGLC ends in 3 weeks on >>> August 12. >>>=20 >> Sorry for writing late. I believe this is a good document and that = we >> should move forward with the recommendation of publishing a well = known >> name for learning the PREF64. This path is consistent with the the >> overall NAT64 / DNS64 philosophy of working within the existing >> technology to the greatest extent possible. >>=20 >> Cameron >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From jouni.nospam@gmail.com Tue Oct 4 06:17:34 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBCB021F8ABE for ; Tue, 4 Oct 2011 06:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[AWL=-0.762, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A+METBcr+agI for ; Tue, 4 Oct 2011 06:17:34 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1154321F8A7B for ; Tue, 4 Oct 2011 06:17:33 -0700 (PDT) Received: by bkaq10 with SMTP id q10so854252bka.31 for ; Tue, 04 Oct 2011 06:20:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=kroncgdxWhrafkrXAqzejl0BMStshwkADxKXO/LQNEs=; b=ky5nznvv0TozTikGRj49ZXoEtHmSotFntV+xlkmad+x6TDfAp4sQT2RSxGTgRGgSvM L0zoJ9B8r/PI/Hdvb06fLYUsqQIGYIah2cb8d8qf9pXiS+dH8njacJcs49wMz4jfo3TA l8Xt0nahZW90ms9LvnB2pfk8aUrXSSjrq0uuY= Received: by 10.204.138.83 with SMTP id z19mr711047bkt.274.1317734438422; Tue, 04 Oct 2011 06:20:38 -0700 (PDT) Received: from a83-245-210-213.elisa-laajakaista.fi (a83-245-210-213.elisa-laajakaista.fi. [83.245.210.213]) by mx.google.com with ESMTPS id z9sm16576217bkn.7.2011.10.04.06.20.36 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 04 Oct 2011 06:20:37 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Tue, 4 Oct 2011 16:20:36 +0300 Content-Transfer-Encoding: 7bit Message-Id: References: <000101cc48b3$a9f87500$fde95f00$@com> To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: behave@ietf.org, draft-ietf-behave-nat64-learn-analysis@tools.ietf.org, Dan Wing Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-nat64-learn-analysis-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 13:17:34 -0000 Hi Cameron, On Sep 6, 2011, at 11:03 PM, Cameron Byrne wrote: > On Fri, Jul 22, 2011 at 2:09 PM, Dan Wing wrote: >> This starts a 3 week WGLC (extra time to accommodate IETF travel) for >> draft-ietf-behave-nat64-learn-analysis-00. This document analyzes the >> available approaches for a host to learn its NAT64 prefix. Abstract: >> >> Hosts and applications may benefit from the knowledge if an IPv6 >> address is synthesized, which would mean a NAT64 is used to reach the >> IPv4 network or Internet. This document analyses a number of >> proposed solutions for communicating whether the synthesis is taking >> place, used address format, and the IPv6 prefix used by the NAT64 and >> DNS64. The solutions enable both NAT64 avoidance and intentional >> utilization by allowing local IPv6 address synthesis. The document >> concludes by recommending selection of heuristic discovery based >> solution. >> >> Please send comments to behave@ietf.org. WGLC ends in 3 weeks on >> August 12. >> > > Sorry for writing late. I believe this is a good document and that we > should move forward with the recommendation of publishing a well known > name for learning the PREF64. This path is consistent with the the > overall NAT64 / DNS64 philosophy of working within the existing > technology to the greatest extent possible. Thanks, Jouni > > Cameron > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From jouni.nospam@gmail.com Tue Oct 4 06:19:40 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B13BD21F8CEE for ; Tue, 4 Oct 2011 06:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.325 X-Spam-Level: X-Spam-Status: No, score=-2.325 tagged_above=-999 required=5 tests=[AWL=-0.686, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MEzNUPSGa1wh for ; Tue, 4 Oct 2011 06:19:40 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 552FA21F8AE6 for ; Tue, 4 Oct 2011 06:19:33 -0700 (PDT) Received: by bkaq10 with SMTP id q10so857150bka.31 for ; Tue, 04 Oct 2011 06:22:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=6zBE7HLwvlexKt0sP9BY5CMqRThNzRSyZ+K410Sjm6w=; b=ty3T5jCcSCdtiovmRsTrroc0Dl/fpLL3C6XUvTVrNiHq/5zlxmAxLIl2l0x9zmG9fr G1D1NK9ObBG8cZAaDax0jBzIguKIyrjUYBxj5R2sO8DP+UpWvDVKbBEPo+4MzzZZCXpX t1xuwo4oMvwz9vcZqJV/z6BjMN79eDDI2gs/I= Received: by 10.204.148.218 with SMTP id q26mr732603bkv.380.1317734557809; Tue, 04 Oct 2011 06:22:37 -0700 (PDT) Received: from a83-245-210-213.elisa-laajakaista.fi (a83-245-210-213.elisa-laajakaista.fi. [83.245.210.213]) by mx.google.com with ESMTPS id l3sm8949576bkv.12.2011.10.04.06.22.35 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 04 Oct 2011 06:22:36 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: jouni korhonen In-Reply-To: <94C682931C08B048B7A8645303FDC9F3516744765B@PUEXCB1B.nanterre.francetelecom.fr> Date: Tue, 4 Oct 2011 16:22:34 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <5F8D1AEE-7C89-44CE-B8A8-C9ABD74A3C47@gmail.com> References: <000101cc48b3$a9f87500$fde95f00$@com> <94C682931C08B048B7A8645303FDC9F3516744765B@PUEXCB1B.nanterre.francetelecom.fr> To: X-Mailer: Apple Mail (2.1084) Cc: "behave@ietf.org" , "draft-ietf-behave-nat64-learn-analysis@tools.ietf.org" , Dan Wing Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-nat64-learn-analysis-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 13:19:40 -0000 Hi Mohammed, On Sep 8, 2011, at 12:34 PM, = wrote: > Dear all, >=20 > The document is in a good shape and I support its publication. Thanks. >=20 > I have one minor comment, the conclusion says:=20 >=20 > "None of the discussed solutions support learning of > possible new or indicating support for multiple algorithms for > address synthesis other than the one described in [RFC6052]." >=20 > Which is not actually true for one of the solutions discussed in = Section 4.6. Please refer to = http://tools.ietf.org/html/draft-boucadair-dhcpv6-shared-address-option-01= #section-5 for more details. Good catch. I will correct the statement in Section 4.6. - Jouni >=20 > Cheers, > Med >=20 >=20 > -----Message d'origine----- > De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la = part de Dan Wing > Envoy=E9 : vendredi 22 juillet 2011 23:10 > =C0 : behave@ietf.org > Cc : draft-ietf-behave-nat64-learn-analysis@tools.ietf.org > Objet : [BEHAVE] WGLC: draft-ietf-behave-nat64-learn-analysis-00 >=20 > This starts a 3 week WGLC (extra time to accommodate IETF travel) for > draft-ietf-behave-nat64-learn-analysis-00. This document analyzes the > available approaches for a host to learn its NAT64 prefix. Abstract: >=20 > Hosts and applications may benefit from the knowledge if an IPv6 > address is synthesized, which would mean a NAT64 is used to reach = the > IPv4 network or Internet. This document analyses a number of > proposed solutions for communicating whether the synthesis is taking > place, used address format, and the IPv6 prefix used by the NAT64 = and > DNS64. The solutions enable both NAT64 avoidance and intentional > utilization by allowing local IPv6 address synthesis. The document > concludes by recommending selection of heuristic discovery based > solution. >=20 > Please send comments to behave@ietf.org. WGLC ends in 3 weeks on=20 > August 12. >=20 > -d >=20 >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From C.Donley@cablelabs.com Wed Oct 5 15:05: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 C378711E80C2 for ; Wed, 5 Oct 2011 15:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.812 X-Spam-Level: * X-Spam-Status: No, score=1.812 tagged_above=-999 required=5 tests=[AWL=-1.434, BAYES_05=-1.11, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id seQ45C2QuzRM for ; Wed, 5 Oct 2011 15:05:22 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7D711E80A1 for ; Wed, 5 Oct 2011 15:05:22 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id p95M8RdU006440 for ; Wed, 5 Oct 2011 16:08:27 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Wed, 5 Oct 2011 16:08:27 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Wed, 5 Oct 2011 16:08:27 -0600 From: Chris Donley To: "'behave@ietf.org'" Date: Wed, 5 Oct 2011 16:08:23 -0600 Thread-Topic: IPR on draft-donley-behave-deterministic-cgn Thread-Index: AcyDq04tzdDt5n5JTieZppTVyJejAg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CAB23177260C6cdonleycablelabscom_" MIME-Version: 1.0 X-Approved: ondar Subject: [BEHAVE] IPR on draft-donley-behave-deterministic-cgn 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, 05 Oct 2011 22:05:22 -0000 --_000_CAB23177260C6cdonleycablelabscom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The WG should be aware of IPR on draft-donley-behave-deterministic-cgn, htt= ps://datatracker.ietf.org/ipr/1617 Chris --_000_CAB23177260C6cdonleycablelabscom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The WG should be aware of IPR o= n draft-donley-behave-deterministic-cgn, https://datatracker.ietf.org/ipr/1617
<= div>

Chris

--_000_CAB23177260C6cdonleycablelabscom_-- From bschlies@cisco.com Wed Oct 5 15:14: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 69FC921F8C93 for ; Wed, 5 Oct 2011 15:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l70PPnLthEHZ for ; Wed, 5 Oct 2011 15:14:28 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id F040F21F8C92 for ; Wed, 5 Oct 2011 15:14:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=1871; q=dns/txt; s=iport; t=1317853057; x=1319062657; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=RjoGz+a+8bYG352u3q7PSvc3gt8mcZQVudRltvefsDM=; b=UfF6DYpnniqAhfDuithFTWLE8BDh8Za1D5Dmohgtf4VOhMdgNBDgYUhv rUL5Z1Z8GukricrNgoMeGL56jNp9MbsVF9zBPnk2XkC4QW+M+x5ioo1MD /C1jAkHb4pOopxKEC2gc2jod9d3xE7939JYIVnAyy4BMMg+N8mv38bYP8 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGTXjE6rRDoH/2dsb2JhbABCgk2lTYEFgVMBAQEBAgESAWYFCwsEAQk4VwY1h1sGmE0Bng8DhkhhBId8i3GFJ4w7 X-IronPort-AV: E=Sophos;i="4.68,494,1312156800"; d="scan'208,217";a="6162026" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 05 Oct 2011 22:17:36 +0000 Received: from [192.168.0.133] (sjc-vpn2-937.cisco.com [10.21.115.169]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p95MHai6012658; Wed, 5 Oct 2011 22:17:36 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-7-243439829 From: Benson Schliesser In-Reply-To: Date: Wed, 5 Oct 2011 17:17:36 -0500 Message-Id: References: To: Chris Donley X-Mailer: Apple Mail (2.1084) Cc: "'behave@ietf.org'" Subject: Re: [BEHAVE] IPR on draft-donley-behave-deterministic-cgn 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, 05 Oct 2011 22:14:28 -0000 --Apple-Mail-7-243439829 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Chris. On Oct 5, 2011, at 5:08 PM, Chris Donley wrote: > The WG should be aware of IPR on = draft-donley-behave-deterministic-cgn, = https://datatracker.ietf.org/ipr/1617 Thanks for pointing this out. Can you also provide a pointer to details = of your patent application? After quickly reading the draft, it's not = clear to me what novel technique you're claiming. Additional clarity = would be appreciated. Cheers, -Benson --Apple-Mail-7-243439829 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi, = Chris.

On Oct 5, 2011, at 5:08 PM, Chris Donley = wrote:

The WG should be = aware of IPR on draft-donley-behave-deterministic-cgn, https://datatracker.ietf.or= g/ipr/1617

Th= anks for pointing this out.  Can you also provide a pointer to = details of your patent application?  After quickly reading the = draft, it's not clear to me what novel technique you're claiming. =  Additional clarity would be = appreciated.

Cheers,
-Benson
=

= --Apple-Mail-7-243439829-- From C.Donley@cablelabs.com Wed Oct 5 16:08: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 A482F11E8083 for ; Wed, 5 Oct 2011 16:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.101 X-Spam-Level: X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[AWL=0.563, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqp80gXdsA5y for ; Wed, 5 Oct 2011 16:08:01 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 853A211E8082 for ; Wed, 5 Oct 2011 16:08:01 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id p95NB6KU014473; Wed, 5 Oct 2011 17:11:06 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Wed, 5 Oct 2011 17:11:06 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Wed, 5 Oct 2011 17:11:06 -0600 From: Chris Donley To: Benson Schliesser Date: Wed, 5 Oct 2011 17:11:03 -0600 Thread-Topic: [BEHAVE] IPR on draft-donley-behave-deterministic-cgn Thread-Index: AcyDtA86rtL2bKwnQeKoJqtJF3OxrA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CAB23BE92616Acdonleycablelabscom_" MIME-Version: 1.0 X-Approved: ondar Cc: "'behave@ietf.org'" Subject: Re: [BEHAVE] IPR on draft-donley-behave-deterministic-cgn 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, 05 Oct 2011 23:08:05 -0000 --_000_CAB23BE92616Acdonleycablelabscom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Benson, I guess the patent app hasn't made it to the USPTO website yet (the app num= ber is in the disclosure - I think you should be able to read it once the p= atent office posts it). From a high level, it claims deterministic nat mapp= ings with an overflow pool, geolocation=96aware 'outside' address bindings= , and an application to reverse the algorithm and identify a user when pres= ented with the IP address and port. Chris -- Chris Donley CCIE, CISSP, SCiPM Project Director - Network Protocols CableLabs=AE 858 Coal Creek Circle Louisville, CO 80027 303-661-3480 (v) 303-661-9199 (f) From: Benson Schliesser > Date: Wed, 5 Oct 2011 16:17:36 -0600 To: Chris Donley > Cc: "'behave@ietf.org'" > Subject: Re: [BEHAVE] IPR on draft-donley-behave-deterministic-cgn Hi, Chris. On Oct 5, 2011, at 5:08 PM, Chris Donley wrote: The WG should be aware of IPR on draft-donley-behave-deterministic-cgn, htt= ps://datatracker.ietf.org/ipr/1617 Thanks for pointing this out. Can you also provide a pointer to details of= your patent application? After quickly reading the draft, it's not clear = to me what novel technique you're claiming. Additional clarity would be ap= preciated. Cheers, -Benson --_000_CAB23BE92616Acdonleycablelabscom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Benson, 

I guess the patent app hasn't made it to the USPTO websit= e yet (the app number is in the disclosure - I think you should be able to = read it once the patent office posts it). From a high level, it claims dete= rministic nat mappings with an overflow pool,  geolocation=96aware 'ou= tside' address bindings, and an application to reverse the algorithm and id= entify a user when presented with the IP address and port.

Chris   
-- 
Chris Donley
CCIE, CISS= P, SCiPM
Project Director - Network Protoco= ls
CableLabs=AE
=
858 Coal Creek Circle
L= ouisville, CO 80027
303-661-3480 (v)=
303-661-9199 (f)

From: Benson Schliesser <bschlies@cisc= o.com>
Date: Wed, 5 Oct = 2011 16:17:36 -0600
To: Chris D= onley <c.donley@cablelabs.com<= /a>>
Cc: "'behave@ietf.org'" <behave@ietf.org>
= Subject: Re: [BEHAVE] IPR on draft-donley-behave-deterministic-cgn<= br>

Hi, Chris.
On Oct 5, 2011, at 5:08 PM, Chris Donley wrote:

The WG should be aware of IPR on draft-donley-behave-deterministic-cg= n, https://datatrack= er.ietf.org/ipr/1617

Thanks for pointing this out.  Can you also provide a pointer t= o details of your patent application?  After quickly reading the draft= , it's not clear to me what novel technique you're claiming.  Addition= al clarity would be appreciated.

Cheers,
-Benson


 --_000_CAB23BE92616Acdonleycablelabscom_-- From wwwrun@rfc-editor.org Wed Oct 5 17:15: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 5724221F8DFE; Wed, 5 Oct 2011 17:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.157 X-Spam-Level: X-Spam-Status: No, score=-102.157 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLLxJ8V45tSE; Wed, 5 Oct 2011 17:15:31 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 54D0F21F8E03; Wed, 5 Oct 2011 17:15:29 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id AF94B98C286; Wed, 5 Oct 2011 17:18:38 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20111006001838.AF94B98C286@rfc-editor.org> Date: Wed, 5 Oct 2011 17:18:38 -0700 (PDT) Cc: behave@ietf.org, rfc-editor@rfc-editor.org Subject: [BEHAVE] RFC 6384 on An FTP Application Layer Gateway (ALG) for IPv6-to-IPv4 Translation 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, 06 Oct 2011 00:15:32 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6384 Title: An FTP Application Layer Gateway (ALG) for IPv6-to-IPv4 Translation Author: I. van Beijnum Status: Standards Track Stream: IETF Date: October 2011 Mailbox: iljitsch@muada.com Pages: 16 Characters: 38126 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-behave-ftp64-12.txt URL: http://www.rfc-editor.org/rfc/rfc6384.txt 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, in situations 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, it is important that FTP is made to work through these translators to the best possible extent. FTP has an active and a passive mode, both as original commands that are IPv4-specific and as extended, IP version agnostic commands. The only FTP mode that works without changes through an IPv6-to-IPv4 translator is extended passive. However, many existing FTP servers do not support this mode, and some clients do not ask for it. This document specifies a middlebox that may solve this mismatch. [STANDARDS-TRACK] This document is a product of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From dwing@cisco.com Wed Oct 5 19:08: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 CF3E11F0C5B for ; Wed, 5 Oct 2011 19:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.999 X-Spam-Level: X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXCb8EP3SdZN for ; Wed, 5 Oct 2011 19:08:15 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id B517B1F0C55 for ; Wed, 5 Oct 2011 19:08:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=3420; q=dns/txt; s=iport; t=1317867084; x=1319076684; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=qykMaHRsSHCZJ/jzW4OBH9Okd3oTtXHcdkVrnMhD6hc=; b=lFBvX9ROaqvxKhv9i+SlLCmF3AEkpVtEEo/6QL4Rapyiw3C11ZD3OjYV R4Yt+zvhYJMijIBVZBAbxgXAM7uv1cBJCkSyAG197KIiWQw05AKBurCQF rm2REqKw+Jg5w+sxt2wsPe8Sp4NqTrG05o1xbbEqY3Zk4278WC9FbZQ/f s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsIAAFENjU6Q/khM/2dsb2JhbABDmQyBbI0pgQWBUwEBAQEDAQEBBQoBFxAUIAsMAQMCCQ8CAwEBAQ0bBxkOCgsKCQgBAQQKCQkCCQcCBAGHYZdvAZ4ChykEh3ydVg X-IronPort-AV: E=Sophos;i="4.68,495,1312156800"; d="scan'208";a="57192919" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 06 Oct 2011 02:11:22 +0000 Received: from dwingWS ([10.32.240.196]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p962BK1t012314; Thu, 6 Oct 2011 02:11:21 GMT From: "Dan Wing" To: References: <20111006001838.AF94B98C286@rfc-editor.org> In-Reply-To: <20111006001838.AF94B98C286@rfc-editor.org> Date: Wed, 5 Oct 2011 19:11:21 -0700 Message-ID: <0dbb01cc83cd$3ee12aa0$bca37fe0$@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: AcyDvZ80ql+cKnAtR+Ck/QNBhkpfLgAD4nSg Content-Language: en-us Subject: Re: [BEHAVE] RFC 6384 on An FTP Application Layer Gateway (ALG) for IPv6-to-IPv4 Translation 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, 06 Oct 2011 02:08:15 -0000 Congrats on another RFC to the working group, and to Iljitsch for seeing this one through. -d > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of rfc-editor@rfc-editor.org > Sent: Wednesday, October 05, 2011 5:19 PM > To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org > Cc: behave@ietf.org; rfc-editor@rfc-editor.org > Subject: [BEHAVE] RFC 6384 on An FTP Application Layer Gateway (ALG) > for IPv6-to-IPv4 Translation > > > A new Request for Comments is now available in online RFC libraries. > > > RFC 6384 > > Title: An FTP Application Layer Gateway > (ALG) for IPv6-to-IPv4 Translation > Author: I. van Beijnum > Status: Standards Track > Stream: IETF > Date: October 2011 > Mailbox: iljitsch@muada.com > Pages: 16 > Characters: 38126 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-behave-ftp64-12.txt > > URL: http://www.rfc-editor.org/rfc/rfc6384.txt > > 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, in situations 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, > it is important that FTP is made to work through these translators to > the best possible extent. > > FTP has an active and a passive mode, both as original commands that > are IPv4-specific and as extended, IP version agnostic commands. The > only FTP mode that works without changes through an IPv6-to-IPv4 > translator is extended passive. However, many existing FTP servers > do not support this mode, and some clients do not ask for it. This > document specifies a middlebox that may solve this mismatch. > [STANDARDS-TRACK] > > This document is a product of the Behavior Engineering for Hindrance > Avoidance Working Group of the IETF. > > This is now a Proposed Standard Protocol. > > STANDARDS TRACK: This document specifies an Internet standards track > protocol for the Internet community,and requests discussion and > suggestions > for improvements. Please refer to the current edition of the Internet > Official Protocol Standards (STD 1) for the standardization state and > status of this protocol. Distribution of this memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see http://www.rfc- > editor.org/rfcsearch.html. > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > Association Management Solutions, LLC > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From internet-drafts@ietf.org Thu Oct 6 02:23: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 9E60B21F8C57; Thu, 6 Oct 2011 02:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGTMy+l6ndPB; Thu, 6 Oct 2011 02:23:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2833621F8B43; Thu, 6 Oct 2011 02:23:56 -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.60 Message-ID: <20111006092356.2375.42924.idtracker@ietfa.amsl.com> Date: Thu, 06 Oct 2011 02:23:56 -0700 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action: draft-ietf-behave-nat64-learn-analysis-01.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 09:23:56 -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-01.txt Pages : 25 Date : 2011-10-06 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-= 01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-nat64-learn-analysis-0= 1.txt From jouni.nospam@gmail.com Thu Oct 6 02:25: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 482D421F8C64 for ; Thu, 6 Oct 2011 02:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.243 X-Spam-Level: X-Spam-Status: No, score=-3.243 tagged_above=-999 required=5 tests=[AWL=0.356, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epD-nkL-1WAS for ; Thu, 6 Oct 2011 02:25:14 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0ED21F8C2D for ; Thu, 6 Oct 2011 02:25:14 -0700 (PDT) Received: by bkaq10 with SMTP id q10so3619106bka.31 for ; Thu, 06 Oct 2011 02:28:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=BUjlaZhjc1XHcxJwVGO/8NpWwtFrovTqLC+/KbJquug=; b=mj0/UXU+Yq/mexxriNbS1VDGzQBnWN1vICJrQAXIQt3/51yn+eSSLRftsxFgqUStRX MFHY39WcEy1i452AYQLzfX6owURiXDMaq1UtSn5myFu3ZvTGx+IYNMEyJZuvDb1imqWj ozr2Goa3mMmEsLpdNIPgEmfp2YqzwROH03NHQ= Received: by 10.204.132.210 with SMTP id c18mr403145bkt.0.1317893303952; Thu, 06 Oct 2011 02:28:23 -0700 (PDT) Received: from a83-245-210-213.elisa-laajakaista.fi (a83-245-210-213.elisa-laajakaista.fi. [83.245.210.213]) by mx.google.com with ESMTPS id v16sm4737459bkd.6.2011.10.06.02.28.22 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 06 Oct 2011 02:28:23 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: jouni korhonen Date: Thu, 6 Oct 2011 12:28:21 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <65119C4D-B1D2-42C0-A06D-A2163BED6275@gmail.com> References: <20111006092356.2375.64134.idtracker@ietfa.amsl.com> To: "behave@ietf.org (behave@ietf.org)" X-Mailer: Apple Mail (2.1084) Cc: Behave Chairs Subject: [BEHAVE] Fwd: New Version Notification for draft-ietf-behave-nat64-learn-analysis-01.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 09:25:15 -0000 FYI. We have reflected the WGLC comments in this revision. Thanks to the = reviewers! - Jouni Begin forwarded message: > From: internet-drafts@ietf.org > Date: October 6, 2011 12:23:56 PM GMT+03:00 > To: jouni.nospam@gmail.com > Cc: jouni.nospam@gmail.com, teemu.savolainen@nokia.com > Subject: New Version Notification for = draft-ietf-behave-nat64-learn-analysis-01.txt >=20 > A new version of I-D, draft-ietf-behave-nat64-learn-analysis-01.txt = has been successfully submitted by Jouni Korhonen and posted to the IETF = repository. >=20 > Filename: draft-ietf-behave-nat64-learn-analysis > Revision: 01 > Title: Analysis of solution proposals for hosts to = learn NAT64 prefix > Creation date: 2011-10-06 > WG ID: behave > Number of pages: 25 >=20 > Abstract: > Hosts and applications may benefit from the knowledge if an IPv6 > address is synthesized, which would mean a NAT64 is used to reach = the > IPv4 network or Internet. This document analyses a number of > proposed solutions for communicating whether the synthesis is taking > place, used address format, and the IPv6 prefix used by the NAT64 = and > DNS64. The solutions enable both NAT64 avoidance and intentional > utilization by allowing local IPv6 address synthesis. The document > concludes by recommending selection of heuristic discovery based > solution. >=20 >=20 >=20 >=20 > The IETF Secretariat From dwing@cisco.com Thu Oct 6 12:16:34 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1482D21F8D7C for ; Thu, 6 Oct 2011 12:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.911 X-Spam-Level: X-Spam-Status: No, score=-102.911 tagged_above=-999 required=5 tests=[AWL=-0.312, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4l-mO9O-6BV for ; Thu, 6 Oct 2011 12:16:33 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 2D10521F8D7B for ; Thu, 6 Oct 2011 12:16:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=9151; q=dns/txt; s=iport; t=1317928784; x=1319138384; h=from:to:subject:date:message-id:mime-version: content-transfer-encoding; bh=pjlVKTd1YOoyq6kHhJ/OfnauZ7LzIfILUNdVJZCFcLc=; b=k+gzfTS5ixc0Y4QsCwqwrj4eqihoEX7bZ8tDPNhT0aXl4qvV3uzzIpGC iwVBRQwkxC8NaK1Y58hKG+He5KYGhhL36APslbanWlG35PD9yMScYzy4I z7WkvnnTXqP0s/xkrjj6WuGP2ANxPJmSAzY0Ip4kHwvCs6FdfOBFr8KPu I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIAAJ3+jU6rRDoG/2dsb2JhbABCmReBbI0wgQWBUwEBAQQICgEXEDEDFwEFCQ8CBAEBKCAjCgcBAQUEAQQTCQIQB4djmT6BJgGeFocsBId9nVc X-IronPort-AV: E=Sophos;i="4.68,498,1312156800"; d="scan'208";a="6349189" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 06 Oct 2011 19:19:43 +0000 Received: from dwingWS ([10.32.240.196]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p96JJhEe005692 for ; Thu, 6 Oct 2011 19:19:43 GMT From: "Dan Wing" To: Date: Thu, 6 Oct 2011 12:19:42 -0700 Message-ID: <106701cc845c$e6c130a0$b44391e0$@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: AcyEXNRk+IcPgxEdTYiu/CQPs6mmiwAAAnqw Content-Language: en-us Subject: [BEHAVE] FW: publication requested, draft-ietf-behave-nat64-learn-analysis-01 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, 06 Oct 2011 19:16:34 -0000 FYI. -d -----Original Message----- From: Dan Wing [mailto:dwing@cisco.com] Sent: Thursday, October 06, 2011 12:19 PM To: 'iesg-secretary@ietf.org' Cc: 'behave-chairs@tools.ietf.org'; 'David Harrington'; 'draft-ietf-behave-nat64-learn-analysis@tools.ietf.org'; 'jouni.korhonen@nsn.com'; 'ext teemu.savolainen@nokia.com' Subject: publication requested, draft-ietf-behave-nat64-learn-analysis-01 The BEHAVE working group has finished its WGLC of draft-ietf-behave-nat64-learn-analysis-01 and requests it be published. PROTO writeup is below. Thanks, -d ----- (1.a) Who is the Document Shepherd for this document? document: draft-ietf-behave-nat64-learn-analysis-01 shepherd: Dan Wing, dwing@cisco.com Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Yes. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Yes, sufficient review has been performed. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML? No concerns. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No concerns. There are no IPR disclosures against this document. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? This document analyzies how well BEHAVE's NAT64 documents resolve the problems described in RFC4966 (which deprecated NAT-PT). Consensus is fairly solid. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No significant conflict with this document has occurred. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.) Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? No such reviews are needed. If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. Intended status: Informational (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. Yes, all references are split. (1.i) Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? This document does not need any IANA action. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? There is nothing in this document defined in a formal language. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. 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. Working Group Summary Was there anything in the WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Concern was raised that we should define a new DNS resource record to retrieve this information, rather than confluding we should do a heuristic. The document explains why the working group reached the conslusion to do a heuristic. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type, or other Expert Review, what was its course (briefly)? In the case of a Media Type Review, on what date was the request posted? Personnel Who is the Document Shepherd for this document? Who is the Responsible Area Director? If the document requires IANA experts(s), insert 'The IANA Expert(s) for the registries in this document are .' shepherd: Dan Wing responsible AD: David Harrington The Document Shepherd MUST send the Document Shepherd Write-Up to the Responsible Area Director and iesg-secretary@ietf.org together with the request to publish the document. The Document Shepherd SHOULD also send the entire Document Shepherd Write-Up to the working group mailing list. If the Document Shepherd feels that information which may prove to be sensitive, may lead to possible appeals, or is personal needs to be written up, it SHOULD be sent in direct email to the Responsible Area Director, because the Document Shepherd Write-Up is published openly in the ID Tracker. Question (1.f) of the Write-Up covers any material of this nature and specifies this more confidential handling. From vicmank@rogers.com Mon Oct 10 10:52: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 877B821F8C3D for ; Mon, 10 Oct 2011 10:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.398 X-Spam-Level: * X-Spam-Status: No, score=1.398 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2EP5EetgQ8H for ; Mon, 10 Oct 2011 10:52:57 -0700 (PDT) Received: from nm28.access.bullet.mail.mud.yahoo.com (nm28.access.bullet.mail.mud.yahoo.com [66.94.237.93]) by ietfa.amsl.com (Postfix) with SMTP id 36BBD21F8C3C for ; Mon, 10 Oct 2011 10:52:57 -0700 (PDT) Received: from [66.94.237.200] by nm28.access.bullet.mail.mud.yahoo.com with NNFMP; 10 Oct 2011 17:52:51 -0000 Received: from [98.139.221.71] by tm11.access.bullet.mail.mud.yahoo.com with NNFMP; 10 Oct 2011 17:52:51 -0000 Received: from [127.0.0.1] by smtp108.rog.mail.bf1.yahoo.com with NNFMP; 10 Oct 2011 17:52:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rogers.com; s=s1024; t=1318269171; bh=6EhJsYMr2/W9WgBShRtr2wmvSumtD6FrI16CdORiLSY=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:Mime-version:Content-type; b=v3BJRem8QqhEUSN9VKcFUyHUcrH3BS6aylOqx40YuJ1CpP7/EoPDGDK1yLzp4A53uNYe9gSDSluMG2GsrIMIE87Lskiy29Hn6u1y9K+bbIBAG3sp/szXA3CX14LTMQ3jwithZDNKtchKegjiR7BPRkTXWFW0mNrUYBSIQYZipaE= X-Yahoo-Newman-Id: 61992.22366.bm@smtp108.rog.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 8._._goVM1l2SzaJv.awb8bnKINoIQI_gjKvYj8QK5uRURU Sz0xyiQ88jK6XnbIt3tMj.KA7aYCAjByoACTthClu3j6zgQLHHi9G23Z6ijc b9BkG7_9lV94KC94029DLZhjD0rQhYuujhlIGFbXWfDPPi_o.KDk06VrF2BV DrWlzH.ifag4T2HPagIgVkPF59ykr8ekE_6HvXG9aFAsIQn2Z6jyIf.WhEvu nIiEcSWt9qGVT2ijQn8CaJAUd9urRaUerai7qpLCNHI.UVZ4uTR6zoTRXUIv kAuDsdvroZzSMVw0f3U4c4sm4n_FO3vz95PnRgQj0obOfWt23TARQQeEZTqc OunqVHnVqP50WJ3hniI7BZm_GiAHU3Jl8IaHKtBlETVdvnbxH6vbP7q7qXiV _O34vRl6hz51Q6q1QU_BNcfP2 X-Yahoo-SMTP: f9g07a.swBDGzI9q2Xty6cZwEaZpJ.WouSaMcQ-- Received: from [192.168.1.2] (vicmank@74.198.164.26 with login) by smtp108.rog.mail.bf1.yahoo.com with SMTP; 10 Oct 2011 10:52:50 -0700 PDT User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Mon, 10 Oct 2011 13:52:48 -0400 From: Victor Kuarsingh To: Message-ID: Thread-Topic: Updated CGN Draft with MPLS/VPN Deployment Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3401099573_17453756" Cc: dthaler@microsoft.com, Dan Wing Subject: [BEHAVE] Updated CGN Draft with MPLS/VPN Deployment 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, 10 Oct 2011 17:52:58 -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_3401099573_17453756 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Behave WG, RE: draft-kuarsingh-lsn-deployment-05 I have re-worked the the LSN over MPLS/VPN draft (originally submitted in 2010). References updated and text updated as well. Updated to refer to CGNs rather then LSN/NAT44 as CGN has seem to become the de-facto standard. In document title now "CGN Deployment with MPLS/VPNs" This draft specifies a architectural model to integrated CGNs using MPLS/VPNs (RFC4364) which has also been testing in production with good results. Regards, Victor Kuarsingh --B_3401099573_17453756 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Behave WG,
<= div id=3D":10o">
RE: draft-kuars= ingh-lsn-deployment-05

I have re-worked the the LSN over MPLS/VPN draft (originally submitted in 2010).  References updated and text updated as well.  Updated to = refer to
CGNs rather then LSN/NAT44 as CGN has seem to become the de-facto standard.=

In document title now "CGN Deployment with MPLS/VPNs"

This draft specifies a architectural model to integrated CGNs using
MPLS/VPNs (RFC4364) which has also been testing in production with good
= results.

Regards,

Victor Kuarsingh
--B_3401099573_17453756-- From rpenno@juniper.net Mon Oct 10 23:09:52 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D589C21F8D86 for ; Mon, 10 Oct 2011 23:09:52 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYkOsA3-Jc6M for ; Mon, 10 Oct 2011 23:09:52 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id D751721F8D85 for ; Mon, 10 Oct 2011 23:09:51 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP; Mon, 10 Oct 2011 23:09:51 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.83.0; Mon, 10 Oct 2011 22:58:34 -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; Tue, 11 Oct 2011 01:58:33 -0400 From: Reinaldo Penno To: "behave@ietf.org" Date: Tue, 11 Oct 2011 01:58:31 -0400 Thread-Topic: New Version Notification for draft-penno-behave-rfc4787-5382-5508-bis-01.txt Thread-Index: AcyHqbOs/qqX641hQTezUqCFzYslIwAMRn/O Message-ID: In-Reply-To: <20111011000658.18632.33832.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.11.0.110726 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [BEHAVE] FW: New Version Notification for draft-penno-behave-rfc4787-5382-5508-bis-01.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 06:09:53 -0000 We updated the draft in order to give people time to read it before next IETF. http://tools.ietf.org/html/draft-penno-behave-rfc4787-5382-5508-bis-01 ------ Forwarded Message A new version of I-D, draft-penno-behave-rfc4787-5382-5508-bis-01.txt has been successfully submitted by Renaldo Penno and posted to the IETF repository. Filename: draft-penno-behave-rfc4787-5382-5508-bis Revision: 01 Title: Network Address Translation (NAT) Behavioral Requirements Updates Creation date: 2011-10-10 WG ID: Individual Submission Number of pages: 10 Abstract: This document clarifies and updates several requirements of RFC4787, RFC5382 and RFC5508 based on operational and development experience. The focus of this document is NAPT44. =20 The IETF Secretariat ------ End of Forwarded Message From victor.kuarsingh@gmail.com Mon Oct 10 09:39:08 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9177521F8C86 for ; Mon, 10 Oct 2011 09:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.707 X-Spam-Level: X-Spam-Status: No, score=-1.707 tagged_above=-999 required=5 tests=[AWL=1.274, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50zjbIXwCay6 for ; Mon, 10 Oct 2011 09:39:07 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 9E06421F8C7E for ; Mon, 10 Oct 2011 09:39:07 -0700 (PDT) Received: by qyk33 with SMTP id 33so4786469qyk.10 for ; Mon, 10 Oct 2011 09:39:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding; bh=3pzA7lMwLY1lGRTa9mwXdWuOG4HUb8/6NFXl4sJnvJI=; b=NLEZGsF5yBLgWeAXYvHuG3vGgIUmT9gTPwfTDHMtf65VY8zP5aWhB4kv8vFC6i0+h+ wfay913Ls54Ssez1964V4bX+uzDAdgNK56T7HBEjTSlybMblif05pQ+7enKHuPkwMs3t clvdMUmaDM3rN4znn0UZVomtWv3aTiitkMhVg= Received: by 10.229.67.159 with SMTP id r31mr4004933qci.92.1318264743195; Mon, 10 Oct 2011 09:39:03 -0700 (PDT) Received: from [192.168.1.2] ([74.198.164.26]) by mx.google.com with ESMTPS id fz9sm2920909qab.13.2011.10.10.09.39.00 (version=SSLv3 cipher=OTHER); Mon, 10 Oct 2011 09:39:02 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Mon, 10 Oct 2011 12:38:59 -0400 From: Victor Kuarsingh To: Message-ID: Thread-Topic: New Version Notification for draft-kuarsingh-lsn-deployment-05.txt In-Reply-To: <20111010163127.27467.39308.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Mailman-Approved-At: Tue, 11 Oct 2011 08:36:17 -0700 Cc: dthaler@microsoft.com, Dan Wing Subject: [BEHAVE] FW: New Version Notification for draft-kuarsingh-lsn-deployment-05.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 16:39:08 -0000 Behave WG, I have re-worked the the LSN over MPLS/VPN draft (originally submitted in 2010). References updated and text updated as well. Updated to refer to CGNs rather then LSN/NAT44 as CGN has seem to become the de-facto standard. In document title now "CGN Deployment with MPLS/VPNs" This draft specifies a architectural model to integrated CGNs using MPLS/VPNs (RFC4364) which has also been testing in production with good results. Regards, Victor Kuarsingh On 11-10-10 12:31 PM, "internet-drafts@ietf.org" wrote: >A new version of I-D, draft-kuarsingh-lsn-deployment-05.txt has been >successfully submitted by Victor Kuarsingh and posted to the IETF >repository. > >Filename: draft-kuarsingh-lsn-deployment >Revision: 05 >Title: CGN Deployment with MPLS/VPNs >Creation date: 2011-10-10 >WG ID: Individual Submission >Number of pages: 18 > >Abstract: > This document specifies a framework to integrate a Network Address > Translation layer into an operator's network to function as a >Carrier > Grade NAT (also known as CGN or Large Scale NAT). CGN is a concept > also described in [I-D.shirasaki-nat444] which specifies NAT444 as a > dual layer translation model. Although operators may wish to deploy > IPv6 to strategically overcome IPv4 exhaustion, near term needs may > not be satisfied with an IPv6 deployment alone. This document > provides a practical integration model which allows CGN to be > integrated into the network meeting the needs of the customer while > being mindful of not disrupting existing services and meeting the > technical challenges that CGN brings. The model includes the use of > MPLS/VPNs defined in [RFC4364] as a tool to achieve this goal. This > document does not intend to defend the merits of CGN. > > > > > >The IETF Secretariat From simon.perreault@viagenie.ca Tue Oct 11 12:12: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 55D7F1F0C36 for ; Tue, 11 Oct 2011 12:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dD3-K0vsA3KM for ; Tue, 11 Oct 2011 12:12:20 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 28F7D1F0C38 for ; Tue, 11 Oct 2011 12:12:08 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:21d:60ff:fed7:e732]) by jazz.viagenie.ca (Postfix) with ESMTPSA id CED3D20D10; Tue, 11 Oct 2011 15:12:02 -0400 (EDT) Message-ID: <4E949502.7000000@viagenie.ca> Date: Tue, 11 Oct 2011 15:12:02 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110720 Thunderbird/5.0 MIME-Version: 1.0 To: Chris Donley References: In-Reply-To: X-Enigmail-Version: 1.2.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Poscic, Kristian \(Kristian\)" , "mohamed.boucadair@orange.com" , "'behave@ietf.org'" Subject: [BEHAVE] draft-donley-behave-deterministic-cgn-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 19:12:21 -0000 Chris, Can you elaborate a little bit on why the overflow pool is necessary? Why isn't static mapping sufficient for the CableLabs use case? Thanks, Simon On 2011-09-26 13:56, Chris Donley wrote: > Filename: draft-donley-behave-deterministic-cgn > Revision: 00 > Title: Deterministic Address Mapping to Reduce Logging in Carrier Grade NATs > Creation date: 2011-09-26 > WG ID: Individual Submission > Number of pages: 9 > > Abstract: > Many Carrier Grade NAT solutions require per-connection logging. > Unfortunately, such logging is not scalable to many residential > broadband services. This document suggests a way to manage Carrier > Grade NAT translations in such a way as to significantly reduce the > amount of logging required while providing traceability for abuse > response. This method also provides a way of including geo-location > significance in such assignments. -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From kristian.poscic@alcatel-lucent.com Wed Oct 12 09:18: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 2351321F8B8B for ; Wed, 12 Oct 2011 09:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22aWUCRyqS7C for ; Wed, 12 Oct 2011 09:18:30 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 863E321F8B61 for ; Wed, 12 Oct 2011 09:18:30 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p9CGINpm001464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 12 Oct 2011 11:18:23 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p9CGIN3R016145 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 12 Oct 2011 11:18:23 -0500 Received: from USNAVSXCHMBSC3.ndc.alcatel-lucent.com ([135.3.39.139]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Wed, 12 Oct 2011 11:18:23 -0500 From: "Poscic, Kristian (Kristian)" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Date: Wed, 12 Oct 2011 11:17:58 -0500 Thread-Topic: [BEHAVE] predictable translations Thread-Index: AcyI+ZA0MqGQVUyPRN+NW2l77jd09gAAE5Eg Message-ID: <2073A6C5467C99478898544C6EBA3F4602BC736803@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> References: <2073A6C5467C99478898544C6EBA3F4602BC3C8163@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> <1E8749B0-224E-4628-9918-0C50F1A3EE01@free.fr> In-Reply-To: <1E8749B0-224E-4628-9918-0C50F1A3EE01@free.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2073A6C5467C99478898544C6EBA3F4602BC736803USNAVSXCHMBSC_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] predictable translations 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, 12 Oct 2011 16:18:32 -0000 --_000_2073A6C5467C99478898544C6EBA3F4602BC736803USNAVSXCHMBSC_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks Remi. I will look at the draft. As you say we will need to exclude certain ports sets (well known ports and= potentially another static port range beyond well known one for static por= t mappings) from deterministic allocation.. But I also like the idea of being able to extend the deterministic port ran= ge with the dynamic port ranges as described in Chris' draft just in case t= hat a user run out of the ports in the deterministic port range. Of course = logging would be used in that case for the dynamic port ranges. Thanks, Kris From: R=E9mi Despr=E9s [mailto:remi.despres@free.fr] Sent: Wednesday, October 12, 2011 9:11 AM To: Poscic, Kristian (Kristian) Cc: behave@ietf.org Subject: Re: [BEHAVE] predictable translations Hi Kris, In a recent draft a purely algorithmic mapping between a Port-set ID of k b= its and 2^k disjoint port sets, none of which includes privileged ports 0-4= 095, has been described (ref Tools.ietf.org/html/draft-despres-softwire-4rd= -addmapping-01). This port-set algorithm hasn't reached WG consensus yet, but seems to be ge= nerally considered as the best candidate for that. If inside addresses have a common prefix of length 32 - k, it can be used A= FAIK for what you are looking for. Regards, RD Le 22 sept. 2011 =E0 20:56, Poscic, Kristian (Kristian) a =E9crit : Hi there - Does anyone knows of any draft that is addressing a more predictable transl= ations between the inside IP and outside IP + port range when it comes to N= AT44. For example in order to avoid logging, IPv4 inside address would be automat= ically (via an algorithm) be converted to an outside IPv4 address + a port= range. This mapping would be unique so that no logging is required. The re= vertive algo would be able to convert the outside IP + port back to the in= side IP. I've seen some drafts addressing something similar in the softwire WG but t= hey all deal with IPv4/IPv6 translations. Thanks, Kris _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave --_000_2073A6C5467C99478898544C6EBA3F4602BC736803USNAVSXCHMBSC_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thanks Remi. I will look at the draft.

As you say we will need to exclude certain ports se= ts (well known ports and potentially another static port range beyond well = known one for static port mappings) from deterministic allocation..

But I also like the idea of being= able to extend the deterministic port range with the dynamic port ranges a= s described in Chris’ draft just in case that a user run out of the p= orts in the deterministic port range. Of course logging would be used in th= at case for the dynamic port ranges.

 

Thanks,<= o:p>

Kris

=

 

From: R=E9mi Despr=E9s [mailto:remi.despres@free.fr]
S= ent: Wednesday, October 12, 2011 9:11 AM
To: Poscic, Kristian= (Kristian)
Cc: behave@ietf.org
Subject: Re: [BEHAVE] p= redictable translations

 

Hi Kris,

 

In = a recent draft a purely algorithmic mapping between a Port-set ID of k bits= and 2^k disjoint port sets, none of which includes privileged ports 0-4095= , has been described (ref Tools.ietf.org/html/draft-despres-softw= ire-4rd-addmapping-01).

<= o:p> 

This port-set algorithm= hasn't reached WG consensus yet, but seems to be generally considered as t= he best candidate for that.

<= o:p> 

If inside addresses hav= e a common prefix of length 32 - k, it can be used AFAIK for what you are l= ooking for.

 =

Regards,

RD

 = ;

 

=

 

Le= 22 sept. 2011 =E0 20:56, Poscic, Kristian (Kristian) a =E9crit :



Hi there –

Does a= nyone knows of any draft that is addressing a more predictable translations= between the inside IP and outside IP + port range when it comes to NAT44.<= o:p>

For example in order to avoid= logging, IPv4 inside address would be automatically (via an algorithm) be = converted to an outside IPv4 address  + a port range. This mapping wou= ld be unique so that no logging is required. The revertive algo would be ab= le to convert the outside IP + port back  to the inside IP.=

 

=

I’ve seen some drafts addressing something similar in t= he softwire WG but they all deal with IPv4/IPv6 translations.

Thanks,

Kris

__________= _____________________________________
Behave mailing list
Behave@ietf.org
https://www.ietf.org/mailman/listinfo/behave

 

= --_000_2073A6C5467C99478898544C6EBA3F4602BC736803USNAVSXCHMBSC_-- From hannes.tschofenig@gmx.net Wed Oct 12 10:53:50 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39F6D21F8B86 for ; Wed, 12 Oct 2011 10:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.325 X-Spam-Level: X-Spam-Status: No, score=-102.325 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e563A9eYzIYY for ; Wed, 12 Oct 2011 10:53:49 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 4D18421F8B72 for ; Wed, 12 Oct 2011 10:53:49 -0700 (PDT) Received: (qmail invoked by alias); 12 Oct 2011 17:53:47 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [10.0.0.4]) [88.115.216.191] by mail.gmx.net (mp071) with SMTP; 12 Oct 2011 19:53:47 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/BnygLRr7BV/hgIlJDruykYn1ErbfcxZ+mmn/X5B A9nv5N8inwem+f From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 12 Oct 2011 20:53:46 +0300 Message-Id: To: behave@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [BEHAVE] IP Fragmentation and Firewalls 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, 12 Oct 2011 17:53:50 -0000 Hi all=20 maybe someone in this group can help me with some literature references.=20= I am looking for measurements of how firewalls treat fragmented IP = packets.=20 I noticed that there are lots of papers on how middleboxes impact = transport layer protocols but I fail to find recent studies about the = impact on the network layer (in particular with regard to IP = fragmentation).=20 Ciao Hannes From dwing@cisco.com Wed Oct 12 15:12: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 C1D8821F8BB5 for ; Wed, 12 Oct 2011 15:12:33 -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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wISK1BzaEHbH for ; Wed, 12 Oct 2011 15:12:33 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF3221F8B86 for ; Wed, 12 Oct 2011 15:12:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1575; q=dns/txt; s=iport; t=1318457553; x=1319667153; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=CbPT1voiGnNuAvyHqjRWic5BzSYpWE+69tI2aFuMDp8=; b=AZhqepZgstpzPy64XUtyviXzpdgcu/NbcDnrFNYfOWHN/9OCh5V7I6yf 0owrnPpwX6rSZdkQ5Na2CiQP8fObtP+yXnFuDWMYKcTM+fFpcSaKUrg58 Bzikw6pYKLuDayD9U0bZ1FnkCVM6tmZTLAbiNQQ0JBpW0zJO/scVqX0pq c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnsAAK8Plk6rRDoG/2dsb2JhbABDmRmBbIsFgjCBBYFTAQEBAQIBAQEBBQoBFxA0EAcBAwIJDwIEAQEoBxkOFQoJCAEBBAESCxeHXAiaPgGeRAOHWASHf51q X-IronPort-AV: E=Sophos;i="4.69,336,1315180800"; d="scan'208";a="7512109" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 12 Oct 2011 22:12:33 +0000 Received: from dwingWS ([128.107.106.161]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9CMCXZY004043; Wed, 12 Oct 2011 22:12:33 GMT From: "Dan Wing" To: "'Hannes Tschofenig'" , References: In-Reply-To: Date: Wed, 12 Oct 2011 15:12:33 -0700 Message-ID: <035501cc892c$0a45ba90$1ed12fb0$@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: AcyJB+n3fmQY9IKiSrG0rPV5Am/ECgAIuR5w Content-Language: en-us Subject: Re: [BEHAVE] IP Fragmentation and Firewalls 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, 12 Oct 2011 22:12:33 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Hannes Tschofenig > Sent: Wednesday, October 12, 2011 10:54 AM > To: behave@ietf.org > Subject: [BEHAVE] IP Fragmentation and Firewalls > > Hi all > > maybe someone in this group can help me with some literature > references. > > I am looking for measurements of how firewalls treat fragmented IP > packets. Some simply drop fragments. Some forward fragments, without looking at them at all, under the assumption that the packet with the header was/will be forwarded (or dropped) appropriately by the firewall and the fragmented packet will cause no harm to the host. Others reassemble the packet. Others only reassemble the packet if the fragments arrived in order. I believe that covers everything that can happen. I know that some of Cisco's firewall will vary their behavior (in those above categories) based on their hardware and software versions, if they are doing higher-level protocol inspection, and so on. > I noticed that there are lots of papers on how middleboxes impact > transport layer protocols but I fail to find recent studies about the > impact on the network layer (in particular with regard to IP > fragmentation). "It depends." M'self, I would give up on IPv4 and worry about how to get this working like we want with IPv6. -d > Ciao > Hannes > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From marka@isc.org Wed Oct 12 19:47:52 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5BF21F8C73 for ; Wed, 12 Oct 2011 19:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5xGP3OBNJ4L for ; Wed, 12 Oct 2011 19:47:51 -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 33D9A21F8C61 for ; Wed, 12 Oct 2011 19:47:51 -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 198C3C941E; Thu, 13 Oct 2011 02:47:34 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (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 54317216C6B; Thu, 13 Oct 2011 02:47:33 +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 1A7411528F70; Thu, 13 Oct 2011 13:47:31 +1100 (EST) To: "Dan Wing" From: Mark Andrews References: <035501cc892c$0a45ba90$1ed12fb0$@com> In-reply-to: Your message of "Wed, 12 Oct 2011 15:12:33 PDT." <035501cc892c$0a45ba90$1ed12fb0$@com> Date: Thu, 13 Oct 2011 13:47:31 +1100 Message-Id: <20111013024731.1A7411528F70@drugs.dv.isc.org> Cc: behave@ietf.org Subject: Re: [BEHAVE] IP Fragmentation and Firewalls 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, 13 Oct 2011 02:47:52 -0000 In message <035501cc892c$0a45ba90$1ed12fb0$@com>, "Dan Wing" writes: > > -----Original Message----- > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > > Behalf Of Hannes Tschofenig > > Sent: Wednesday, October 12, 2011 10:54 AM > > To: behave@ietf.org > > Subject: [BEHAVE] IP Fragmentation and Firewalls > > > > Hi all > > > > maybe someone in this group can help me with some literature > > references. > > > > I am looking for measurements of how firewalls treat fragmented IP > > packets. > > Some simply drop fragments. Some forward fragments, without looking at them > at all, under the assumption that the packet with the header was/will be > forwarded (or dropped) appropriately by the firewall and the fragmented > packet will cause no harm to the host. Others reassemble the packet. > Others only reassemble the packet if the fragments arrived in order. I > believe that covers everything that can happen. I know that some of Cisco's > firewall will vary their behavior (in those above categories) based on their > hardware and software versions, if they are doing higher-level protocol > inspection, and so on. > > > I noticed that there are lots of papers on how middleboxes impact > > transport layer protocols but I fail to find recent studies about the > > impact on the network layer (in particular with regard to IP > > fragmentation). > > "It depends." > > M'self, I would give up on IPv4 and worry about how to get this working like > we want with IPv6. Fragmentation happens in IPv6 as well. Anything doing DNSSEC will receive/generate fragmented UDP. IPv4 and IPv6. Lots of corporate firewalls have been fixed to pass fragemented IP in the last couple of years as DNSSEC has been rolled out. If you want to test whether the path between your recursive server and the rest of the world actually supports the recommended EDNS packet sizes try the following lookups. dig edns-v6-ok.isc.org TXT dig edns-v4-ok.isc.org TXT The servers are specially configured to only use UDP and the response is sized to return a 4096 octet DNS message. Your recursive server will add a few extra bytes. If you want to test the firewall directly use the following queries which simular a modern recursive server. dig edns-v6-ok.isc.org TXT +dnssec +norec @edns-v6-ok.isc.org dig edns-v4-ok.isc.org TXT +dnssec +norec @edns-v4-ok.isc.org Mark > -d > > > > Ciao > > Hannes > > > > _______________________________________________ > > 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From swmike@swm.pp.se Wed Oct 12 22:52: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 76E7521F8B0F for ; Wed, 12 Oct 2011 22:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.974 X-Spam-Level: X-Spam-Status: No, score=-1.974 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RrypWdqLdVtj for ; Wed, 12 Oct 2011 22:52:27 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id D30E821F8AF8 for ; Wed, 12 Oct 2011 22:52:26 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 5BAD49C; Thu, 13 Oct 2011 07:52:23 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 5662F9A; Thu, 13 Oct 2011 07:52:23 +0200 (CEST) Date: Thu, 13 Oct 2011 07:52:23 +0200 (CEST) From: Mikael Abrahamsson To: Hannes Tschofenig In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: behave@ietf.org Subject: Re: [BEHAVE] IP Fragmentation and Firewalls 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, 13 Oct 2011 05:52:27 -0000 On Wed, 12 Oct 2011, Hannes Tschofenig wrote: > I am looking for measurements of how firewalls treat fragmented IP > packets. Not specifically a firewall but instead a router, but this might be of interest. A Cisco 7600 with PFC3B and earler, will by default punt all IPv6 packets with fragmentation header to RP, meaning the aggregate forwarding performance is going to be a lot lower than if this is just handled in fast-path. There are a *lot* of these routers out there. There is a command to fast-path either forward (bypassing ACLs) or drop these packets. We ran into this problem, a lot of the 6to4/Teredo traffic seems to have fragmentation headers (don't know which, this was the router connecting our Teredo relay, and a majority of the traffic seen there is Teredo <-> 6to4 traffic. PFC3C fixes this, btw. -- Mikael Abrahamsson email: swmike@swm.pp.se From hannes.tschofenig@gmx.net Thu Oct 13 00:31: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 8798B21F8922 for ; Thu, 13 Oct 2011 00:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.064 X-Spam-Level: X-Spam-Status: No, score=-102.064 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkof0NfDXoV0 for ; Thu, 13 Oct 2011 00:31:51 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 9CEF421F891D for ; Thu, 13 Oct 2011 00:31:50 -0700 (PDT) Received: (qmail invoked by alias); 13 Oct 2011 07:31:48 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [10.0.0.4]) [88.115.216.191] by mail.gmx.net (mp071) with SMTP; 13 Oct 2011 09:31:48 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19qdktYEyhqAtATYYvTXsjRD/y+G6OzMp1q/bmo5E FXbJnbsm8MMQ6q Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Thu, 13 Oct 2011 10:31:46 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <53678E88-8B1C-4220-A076-2504C1F933B8@gmx.net> References: To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: behave@ietf.org Subject: Re: [BEHAVE] IP Fragmentation and Firewalls 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, 13 Oct 2011 07:31:51 -0000 Hi Mikael,=20 yes, a regular router (or a NAT) is also of interest (not only a = firewall). Particularly, the home Internet gateway environment is an = area where I believe there could be lots of problems.=20 I know that firewalls can easily be configured to drop these packets and = I could imagine that many admins enable it.=20 However, I would like to have some measurement data.=20 Ciao Hannes =20 On Oct 13, 2011, at 8:52 AM, Mikael Abrahamsson wrote: > On Wed, 12 Oct 2011, Hannes Tschofenig wrote: >=20 >> I am looking for measurements of how firewalls treat fragmented IP = packets. >=20 > Not specifically a firewall but instead a router, but this might be of = interest. A Cisco 7600 with PFC3B and earler, will by default punt all = IPv6 packets with fragmentation header to RP, meaning the aggregate = forwarding performance is going to be a lot lower than if this is just = handled in fast-path. There are a *lot* of these routers out there. >=20 > There is a command to fast-path either forward (bypassing ACLs) or = drop these packets. >=20 > We ran into this problem, a lot of the 6to4/Teredo traffic seems to = have fragmentation headers (don't know which, this was the router = connecting our Teredo relay, and a majority of the traffic seen there is = Teredo <-> 6to4 traffic. >=20 > PFC3C fixes this, btw. >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se From swmike@swm.pp.se Thu Oct 13 01:26: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 B3BEE21F8A57 for ; Thu, 13 Oct 2011 01:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.279 X-Spam-Level: X-Spam-Status: No, score=-2.279 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qyMzMY0oat5d for ; Thu, 13 Oct 2011 01:26:02 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 66C3621F84AE for ; Thu, 13 Oct 2011 01:25:56 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 1E0549C; Thu, 13 Oct 2011 10:25:54 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 1BA9D9A; Thu, 13 Oct 2011 10:25:54 +0200 (CEST) Date: Thu, 13 Oct 2011 10:25:54 +0200 (CEST) From: Mikael Abrahamsson To: Hannes Tschofenig In-Reply-To: <53678E88-8B1C-4220-A076-2504C1F933B8@gmx.net> Message-ID: References: <53678E88-8B1C-4220-A076-2504C1F933B8@gmx.net> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: behave@ietf.org Subject: Re: [BEHAVE] IP Fragmentation and Firewalls 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, 13 Oct 2011 08:26:02 -0000 On Thu, 13 Oct 2011, Hannes Tschofenig wrote: > yes, a regular router (or a NAT) is also of interest (not only a > firewall). Particularly, the home Internet gateway environment is an > area where I believe there could be lots of problems. Oki, just to be clear for everybody, Cisco 7600 is a L3 switch(/router) with 40 gigabit/s per slot capacity, a lot of people use it for core/aggregation purposes. -- Mikael Abrahamsson email: swmike@swm.pp.se From dwing@cisco.com Thu Oct 13 16:55: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 133D721F8B7E for ; Thu, 13 Oct 2011 16:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.442 X-Spam-Level: X-Spam-Status: No, score=-104.442 tagged_above=-999 required=5 tests=[AWL=2.157, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYBf8L3sQ6tR for ; Thu, 13 Oct 2011 16:55:01 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4D021F8AD9 for ; Thu, 13 Oct 2011 16:55:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=928; q=dns/txt; s=iport; t=1318550101; x=1319759701; h=from:to:subject:date:message-id:mime-version: content-transfer-encoding; bh=lJk7Kf6bvzboWsqFM6O0SfYDu4+T2l8N86X8jSjESq0=; b=kZTrY2niGhwIfs7h8Tzl7Bau1P+0yd0yew5UzsiRDMKssSn711MiEqSI 9W9Gc54FqG8+gEGv6Wt0y4l59m0gNDhkkJSPY97bXBmfNmOZBXsI/NAWl nYxV3IkQMP3hJsxrRbHOBzUpH/WcOBMt/G/+G8sQNlBl7Jz5wV80snWvM I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak8IAHp5l06rRDoH/2dsb2JhbAA5Cpl4gSmNOoEFgVoICgEXEEwFGFAjHAEEHheHZJddgSYBniaEPoMvBIgBnWw X-IronPort-AV: E=Sophos;i="4.69,343,1315180800"; d="scan'208";a="7752008" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 13 Oct 2011 23:54:55 +0000 Received: from dwingWS ([10.32.240.197]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9DNssEX023526 for ; Thu, 13 Oct 2011 23:54:54 GMT From: "Dan Wing" To: Date: Thu, 13 Oct 2011 16:54:54 -0700 Message-ID: <02d001cc8a03$817f99a0$847ecce0$@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: AcyKA4E9VG18ZrDOQnOxB7JEGhRpwQ== Content-Language: en-us Subject: [BEHAVE] CGN Requirements: logging (draft-ietf-behave-lsn-requirements) 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, 13 Oct 2011 23:55:02 -0000 The current text in http://tools.ietf.org/html/draft-ietf-behave-lsn-requirements-03#section-4 implies that a CGN needs to log destinations. As we all know, there are two significant drawbacks to destination logging: * if more than one user is visiting the same site, destination logging doesn't help distinguish between those users. Source port logging does. The corollary is that destination logging helps identify a user visiting an unpopular server when that unpopular server is not logging source port. * destination logging creates privacy issues. To align draft-ietf-behave-lsn-requirements with RFC6302 ("Logging Recommendations for Internet-Facing Servers"), should draft-ietf-behave-lsn-requirements instead state that destination logging SHOULD NOT be performed, and recommend that a CGN simply do source port logging in anticipation of servers following RFC6302? -d From ssenthil@cisco.com Thu Oct 13 19:50: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 BB4E421F8C1D for ; Thu, 13 Oct 2011 19:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1UkeR4iSKhwk for ; Thu, 13 Oct 2011 19:50:13 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 594F621F8C10 for ; Thu, 13 Oct 2011 19:50:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ssenthil@cisco.com; l=1468; q=dns/txt; s=iport; t=1318560613; x=1319770213; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=OssFeglwjGIutu7IMgezoKlHCnSiDOe1myVCSxOAL1c=; b=OJfraUAKhkzmK2xy7w0SuwVTlJUhQ3L0TxPA/lNPtyu9sgAxF8yZn1qt z7TNU9JSljDOA1afTYbLZa3ALoyUmu+8q7l4YS4/MrWOmDsjFecI3bSmF Rbv5LQs461sndklTOWEv6rmj/M7AMy6zJSBf6KLxUAMCtuZXzWMY5uO4l k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOeil06rRDoJ/2dsb2JhbAA5CqhagQWBUwEBAQECAQEBAQ8BJwIBMRANAQgJBV8wAQEEARIih1wImQYBni+EPoMvBIxqhw2FMYxA X-IronPort-AV: E=Sophos;i="4.69,343,1315180800"; d="scan'208";a="7795513" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 14 Oct 2011 02:50:13 +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 p9E2oDSS011076 for ; Fri, 14 Oct 2011 02:50:13 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); Thu, 13 Oct 2011 19:50:13 -0700 Received: from 10.82.226.90 ([10.82.226.90]) by xmb-sjc-236.amer.cisco.com ([128.107.191.121]) with Microsoft Exchange Server HTTP-DAV ; Fri, 14 Oct 2011 02:50:12 +0000 User-Agent: Microsoft-Entourage/12.31.0.110725 Date: Thu, 13 Oct 2011 22:50:11 -0400 From: ssenthil To: Dan Wing , Message-ID: Thread-Topic: [BEHAVE] CGN Requirements: logging (draft-ietf-behave-lsn-requirements) Thread-Index: AcyKA4E9VG18ZrDOQnOxB7JEGhRpwQAGHxX0 In-Reply-To: <02d001cc8a03$817f99a0$847ecce0$@com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 14 Oct 2011 02:50:13.0002 (UTC) FILETIME=[FEC5AEA0:01CC8A1B] Subject: Re: [BEHAVE] CGN Requirements: logging (draft-ietf-behave-lsn-requirements) 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, 14 Oct 2011 02:50:13 -0000 On 10/13/11 7:54 PM, "Dan Wing" wrote: > The current text in > http://tools.ietf.org/html/draft-ietf-behave-lsn-requirements-03#section-4 > implies that a CGN needs to log destinations. > > As we all know, there are two significant drawbacks to destination > logging: > > * if more than one user is visiting the same site, destination > logging doesn't help distinguish between those users. Source port > logging does. The corollary is that destination logging helps > identify a user visiting an unpopular server when that unpopular > server is not logging source port. The destination information logged in conjunction with the translated source address/port information and original source address/port (or subscriber identification) can uniquely identify a user behind the CGN even if there are multiple users accessing the same destination. > * destination logging creates privacy issues. > > To align draft-ietf-behave-lsn-requirements with RFC6302 ("Logging > Recommendations for Internet-Facing Servers"), should > draft-ietf-behave-lsn-requirements instead state that destination > logging SHOULD NOT be performed, and recommend that a CGN simply > do source port logging in anticipation of servers following > RFC6302? > > -d > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From swmike@swm.pp.se Thu Oct 13 20:06: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 416A821F85A7 for ; Thu, 13 Oct 2011 20:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZKgJNPDFGBL for ; Thu, 13 Oct 2011 20:06:32 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id AEBD221F861E for ; Thu, 13 Oct 2011 20:06:32 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 763D09C; Fri, 14 Oct 2011 05:06:29 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 7290B9A; Fri, 14 Oct 2011 05:06:29 +0200 (CEST) Date: Fri, 14 Oct 2011 05:06:29 +0200 (CEST) From: Mikael Abrahamsson To: ssenthil In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: behave@ietf.org, Dan Wing Subject: Re: [BEHAVE] CGN Requirements: logging (draft-ietf-behave-lsn-requirements) 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, 14 Oct 2011 03:06:33 -0000 On Thu, 13 Oct 2011, ssenthil wrote: >> * if more than one user is visiting the same site, destination >> logging doesn't help distinguish between those users. Source port >> logging does. The corollary is that destination logging helps >> identify a user visiting an unpopular server when that unpopular >> server is not logging source port. > > The destination information logged in conjunction with the translated source > address/port information and original source address/port (or subscriber > identification) can uniquely identify a user behind the CGN even if there > are multiple users accessing the same destination. If the server is logging source port then destination based logging isn't needed as far as I can see. If the server doesn't log source port, then destination based logging doesn't help for popular sites because they're going to be for the same IP/port anyway. I support recommendation doing only source port logging, I am a huge fan of bulk port allocation and only logging these bindings and never log destination based. Logging destination based has both practical (huge log volume) and privacy implications. -- Mikael Abrahamsson email: swmike@swm.pp.se From linfeng.john.zheng@gmail.com Thu Oct 13 22:59: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 A487F21F8C3F for ; Thu, 13 Oct 2011 22:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.148 X-Spam-Level: X-Spam-Status: No, score=-1.148 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6XtrZi+1sGW for ; Thu, 13 Oct 2011 22:59:57 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id B676B21F8C3E for ; Thu, 13 Oct 2011 22:59:57 -0700 (PDT) Received: by iabn5 with SMTP id n5so2170676iab.31 for ; Thu, 13 Oct 2011 22:59:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=Bt5LkZQcGTE6y2vUjA2YM/tGt1E9W8NaV6JKlBQqG7c=; b=azu4WKXp6x03ibafdMtY3FEzC4I0iB2T6+yLQ9l05QJGcb5s8dHJCrgvZG9/33ROh3 8DWfXrbvckVBQ2fFkQw4dorwESUKbT9ht7nA2Km04JL4E8DA/5nVhqrnF9IoqfkB6O90 5pCtnvvroHfuaxjFyixo3m/eX7Bxk5X/XFLeY= MIME-Version: 1.0 Received: by 10.231.70.131 with SMTP id d3mr3025336ibj.90.1318571997165; Thu, 13 Oct 2011 22:59:57 -0700 (PDT) Received: by 10.231.153.66 with HTTP; Thu, 13 Oct 2011 22:59:57 -0700 (PDT) Date: Fri, 14 Oct 2011 13:59:57 +0800 Message-ID: From: Linfeng Zheng To: behave@ietf.org Content-Type: multipart/alternative; boundary=0015176f131280781e04af3bf7cf Subject: Re: [BEHAVE] Last Call: 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, 14 Oct 2011 05:59:58 -0000 --0015176f131280781e04af3bf7cf Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: GangChen [mailto:phdgang at gmail.com] > Sent: Friday, September 30, 2011 2:53 AM > To: Dan Wing > Cc: Hui Deng; behave at ietf.org; ietf at ietf.org; softwires at ietf.org= ; > Cameron Byrne > Subject: Re: [BEHAVE] Last Call: > (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard > > >> > >> Option 1: > >> > >> +---------------+ > >> |BIH(FTP sever) |----------NAT64-------FTP Client > >> +---------------+ > >> > >> > >> Option 2: > >> > >> +---------------+ > >> |BIH(FTP sever) |--------------FTP Client > >> +---------------+ > >> > >> In the case of Option 1, it can't work since NAT64 couldn't support > >> IPv4 initiated session > > > > I agree it would fail with a passive-mode transfer. But it should > > work with an active-mode transfer. > > > >> In an active-mode transfer, IPv4 client needs initiate the TCP >> connection to a port on the FTP sever in advance. Afterwards, FTP >> server connects back to the client. >> I'm not sure how could NAT64 support the first step (i.e. IPv4 >> initiated TCP connection)? >Static mapping in the NAT64, for the FTP control channel (port >21 or an alternate port). That could be done by the user's >profile (draft-cheng-behave-nat-fwd-port-radius-ext), PCP, or >a web portal that manages the NAT64's configuration. Would HI-NAT works? >-d > Many thanks > > Gang Thanks, John =D6=A3=C1=D6=B7=E5 John Linfeng Zheng =B5=E7=BB=B0=A3=A8Tel): 86-25-8577-1689 =CA=D6=BB=FA=A3=A8Mobile): 15195762065 --0015176f131280781e04af3bf7cf Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable 
> -----Original Message-----
> From: GangChen [mailto:phd=
gang at gmail.com]
> Sent: Friday, September 30, 2011 2:53 AM
> To: Dan Wing
> Cc: Hui Deng; behave at ietf.org; ietf=
 at ietf.org; softwires at ietf.org;
> Cameron Byrne
> Subject: Re: [BEHAVE] Last Call: <draft-ietf-behave-v4v6-bih-06.txt=
>
> (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Propose=
d Standard
>=20
> >>
> >> Option 1:
> >>
> >> +---------------+
> >> |BIH(FTP sever) |----------NAT64-------FTP Client
> >> +---------------+
> >>
> >>
> >> Option 2:
> >>
> >> +---------------+
> >> |BIH(FTP sever) |--------------FTP Client
> >> +---------------+
> >>
> >> In the case of Option 1, it can't work since NAT64 couldn=
't support
> >> IPv4 initiated session
> >
> > I agree it would fail with a passive-mode transfer.  But it shoul=
d
> > work with an active-mode transfer.
> >
>=20
>> In an active-mode transfer, IPv4 client needs initiate the TCP
>> connection to a port on the FTP sever in advance. Afterwards, FTP
>> server connects back to the client.
>> I'm not sure how could NAT64 support the first step (i.e. IPv4
>> initiated TCP connection)?

>Static mapping in the NAT64, for the FTP control channel (port
>21 or an alternate port).  That could be done by the user's
>profile (draft-cheng-behave-nat-fwd-port-radius-ext), PCP, or
>a web portal that manages the NAT64's configuration.

 
Would HI-NAT works?

>-d


> Many thanks
>=20
> Gang
Thanks, John
 
=D6=A3=C1=D6=B7=E5 John Linfeng Zheng
=B5=E7=BB=B0=A3=A8Tel): 86-25-8577-1689
=CA=D6=BB=FA=A3=A8Mobile): 15195762065

--0015176f131280781e04af3bf7cf-- From linfeng.john.zheng@gmail.com Thu Oct 13 23:03: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 E08A621F8C2A for ; Thu, 13 Oct 2011 23:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.322 X-Spam-Level: X-Spam-Status: No, score=0.322 tagged_above=-999 required=5 tests=[AWL=-1.470, BAYES_50=0.001, CN_BODY_35=0.339, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MI9-lWRdyqdo for ; Thu, 13 Oct 2011 23:03:13 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id E607721F8C1F for ; Thu, 13 Oct 2011 23:03:12 -0700 (PDT) Received: by iabn5 with SMTP id n5so2174238iab.31 for ; Thu, 13 Oct 2011 23:03:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=ZGfR3UebE/xBf3/2fGbqoCiYCeMz4/PyysXzJjg8Wws=; b=dA3BSHNnwcdz7YBeEEGm9uNjn5Wa3Wu4F2ec+JASX4dOtsSIg4vGQB/Ep5bZ+U0eoA z7k2XGUxXnEkkb9xns2Qo9JJnN2hjgs6bj7XQreFNKRh0fVIRfFT3u8y/bmOJbYbp3vC W7jW3ZVgKGe9/ZrP8oqJUH3H6cwPVGPWsnA60= MIME-Version: 1.0 Received: by 10.231.70.131 with SMTP id d3mr3029090ibj.90.1318572192449; Thu, 13 Oct 2011 23:03:12 -0700 (PDT) Received: by 10.231.153.66 with HTTP; Thu, 13 Oct 2011 23:03:12 -0700 (PDT) In-Reply-To: References: Date: Fri, 14 Oct 2011 14:03:12 +0800 Message-ID: From: Linfeng Zheng To: behave@ietf.org Content-Type: multipart/alternative; boundary=0015176f131224443104af3c03b9 Subject: [BEHAVE] Fwd: Last Call: 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, 14 Oct 2011 06:03:14 -0000 --0015176f131224443104af3c03b9 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable I means Host-initiated NAT464. I had a draft http://tools.ietf.org/id/draft-zheng-host-initiated-nat-01.tx= t, expired though. It seems work for active-tranfer, too. - John CCIE#8670 ---------- =D2=D1=D7=AA=B7=A2=D3=CA=BC=FE ---------- =B7=A2=BC=FE=C8=CB=A3=BA Linfeng Zheng =C8=D5=C6=DA=A3=BA 2011=C4=EA10=D4=C214=C8=D5 =CF=C2=CE=E71:59 =D6=F7=CC=E2=A3=BA Re: [BEHAVE] Last Call: =CA=D5=BC=FE=C8=CB=A3=BA behave@ietf.org > -----Original Message----- > From: GangChen [mailto:phdgang at gmail.com] > Sent: Friday, September 30, 2011 2:53 AM > To: Dan Wing > Cc: Hui Deng; behave at ietf.org; ietf at ietf.org; softwires at ietf.org= ; > Cameron Byrne > Subject: Re: [BEHAVE] Last Call: > (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard > > >> > >> Option 1: > >> > >> +---------------+ > >> |BIH(FTP sever) |----------NAT64-------FTP Client > >> +---------------+ > >> > >> > >> Option 2: > >> > >> +---------------+ > >> |BIH(FTP sever) |--------------FTP Client > >> +---------------+ > >> > >> In the case of Option 1, it can't work since NAT64 couldn't support > >> IPv4 initiated session > > > > I agree it would fail with a passive-mode transfer. But it should > > work with an active-mode transfer. > > > >> In an active-mode transfer, IPv4 client needs initiate the TCP >> connection to a port on the FTP sever in advance. Afterwards, FTP >> server connects back to the client. >> I'm not sure how could NAT64 support the first step (i.e. IPv4 >> initiated TCP connection)? >Static mapping in the NAT64, for the FTP control channel (port >21 or an alternate port). That could be done by the user's >profile (draft-cheng-behave-nat-fwd-port-radius-ext), PCP, or >a web portal that manages the NAT64's configuration. Would HI-NAT works? >-d > Many thanks > > Gang Thanks, John =D6=A3=C1=D6=B7=E5 John Linfeng Zheng =B5=E7=BB=B0=A3=A8Tel): 86-25-8577-1689 =CA=D6=BB=FA=A3=A8Mobile): 15195762065 --=20 =B9=E2=C3=F7=CB=F9=BD=E1=B5=C4=B9=FB=D7=D3=BE=CD=CA=C7=D2=BB=C7=D0=C1=BC=C9= =C6=A1=A2=B9=AB=D2=E5=A1=A2=B3=CF=CA=B5=A1=A3 =B8=A55:9 =D6=A3=C1=D6=B7=E5 John Linfeng Zheng =B5=E7=BB=B0=A3=A8Tel): 86-25-8577-1689 =CA=D6=BB=FA=A3=A8Mobile): 15195762065 --0015176f131224443104af3c03b9 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
I means Host-initiated NAT464.
 
 
It seems work for active-tranfer, too.
 
- John CCIE#8670

---------- =D2=D1=D7=AA=B7=A2=D3=CA=BC=FE ------= ----
=B7=A2=BC=FE=C8=CB=A3=BA Linfeng Zhen= g <linfeng.john.zheng@gmail.com>
=C8=D5=C6=DA=A3=BA 2011=C4=EA10=D4=C214=C8=D5 =CF=C2=CE=E71:59
=D6=F7=CC= =E2=A3=BA Re: [BEHAVE] Last Call: <draft-ietf-behave-v4v6-bih-06.txt>=
=CA=D5=BC=FE=C8=CB=A3=BA behave@ietf= .org


> -----Original Message-----
> From: GangChen [mailto:phdgang at gmail.com]
> Sent: Friday, September 30, 2011 2:53 AM
> To: Dan Wing
> Cc: Hui Deng; behave at ietf.org; ietf at ietf.=
org; softwires at ietf.o=
rg;
> Cameron Byrne
> Subject: Re: [BEHAVE] Last Call: <draft-ietf-behave-v4v6-bih-06.txt=
>
> (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Propose=
d Standard
>=20
> >>
> >> Option 1:
> >>
> >> +---------------+
> >> |BIH(FTP sever) |----------NAT64-------FTP Client
> >> +---------------+
> >>
> >>
> >> Option 2:
> >>
> >> +---------------+
> >> |BIH(FTP sever) |--------------FTP Client
> >> +---------------+
> >>
> >> In the case of Option 1, it can't work since NAT64 couldn=
't support
> >> IPv4 initiated session
> >
> > I agree it would fail with a passive-mode transfer.  But it shoul=
d
> > work with an active-mode transfer.
> >
>=20
>> In an active-mode transfer, IPv4 client needs initiate the TCP
>> connection to a port on the FTP sever in advance. Afterwards, FTP
>> server connects back to the client.
>> I'm not sure how could NAT64 support the first step (i.e. IPv4
>> initiated TCP connection)?

>Static mapping in the NAT64, for the FTP control channel (port
>21 or an alternate port).  That could be done by the user's
>profile (draft-cheng-behave-nat-fwd-port-radius-ext), PCP, or
>a web portal that manages the NAT64's configuration.

 
Would HI-NAT works?

>-d


> Many thanks
>=20
> Gang
Thanks, John
 
=D6=A3=C1=D6=B7=E5 John Linfeng Zheng
=B5=E7=BB=B0=A3=A8Tel): 86-25-8577-1689
=CA=D6=BB=FA=A3=A8Mobile): 15195762065




--
=B9=E2=C3=F7=CB=F9=BD=E1=B5=C4=B9=FB=D7=D3=BE=CD=CA=C7=D2=BB=C7=D0=C1= =BC=C9=C6=A1=A2=B9=AB=D2=E5=A1=A2=B3=CF=CA=B5=A1=A3    =    =B8=A55:9
 
=D6=A3=C1=D6=B7=E5 John Linfeng Zheng
=B5=E7=BB=B0=A3=A8Tel): 86-25-8577-1689
=CA=D6=BB=FA=A3=A8Mobile): 15195762065

--0015176f131224443104af3c03b9-- From internet-drafts@ietf.org Fri Oct 14 02:55: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 228ED21F8B74; Fri, 14 Oct 2011 02:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id be6RPbIs0U24; Fri, 14 Oct 2011 02:55:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B583221F8B5D; Fri, 14 Oct 2011 02:55:29 -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.60 Message-ID: <20111014095529.8424.2900.idtracker@ietfa.amsl.com> Date: Fri, 14 Oct 2011 02:55:29 -0700 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-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: Fri, 14 Oct 2011 09:55:30 -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-03.txt Pages : 8 Date : 2011-10-14 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 well-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-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-nat64-discovery-heuris= tic-03.txt From teemu.savolainen@nokia.com Fri Oct 14 03:16: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 883A521F899F for ; Fri, 14 Oct 2011 03:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.67 X-Spam-Level: X-Spam-Status: No, score=-2.67 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFS1d+gRYmiW for ; Fri, 14 Oct 2011 03:16:46 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id D396621F8AAF for ; Fri, 14 Oct 2011 03:16:45 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p9EAGO5E007546 for ; Fri, 14 Oct 2011 13:16:44 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Oct 2011 13:16:29 +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; Fri, 14 Oct 2011 12:16:29 +0200 Received: from 008-AM1MPN1-037.mgdnok.nokia.com ([169.254.7.8]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0339.002; Fri, 14 Oct 2011 12:16:29 +0200 From: To: Thread-Topic: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-03.txt Thread-Index: AcyKWSd95AxVeNXARCeS7c+DjWaeYQ== Date: Fri, 14 Oct 2011 10:16:28 +0000 Message-ID: <916CE6CF87173740BC8A2CE4430969620377FBE6@008-AM1MPN1-037.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Company Confidential;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IiK+ntKbo4xPTApCTPxRn9XGhbBnmCVqn5Q5Oymo/pQG4Q2g2yALHK/AW/m+afozOvOn+8bMVc7Zy6+hIsveiaJv2t2ay8D5H9ksn8ChoW+XSLkEgULgaNN7v9tatqj7o9bV8ts1REdJECYc4JY+bnyaBrJmM7/kh+gQ3QDfTmxSH28FpUhrcDaN9Sf5bSAI0FxoInWxWn4MH/pDjX6TQcGZZm4V2Hi/0dmqycaJTylyjDG3ItYX5rJseQqAqZwERVgi+FQGKyNSdlnjJQ1F1hw= x-originating-ip: [10.162.93.230] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0073_01CC8A73.7ACF2650" MIME-Version: 1.0 X-OriginalArrivalTime: 14 Oct 2011 10:16:29.0814 (UTC) FILETIME=[56FEF160:01CC8A5A] X-Nokia-AV: Clean Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-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: Fri, 14 Oct 2011 10:16:46 -0000 ------=_NextPart_000_0073_01CC8A73.7ACF2650 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Please see updated version of the draft. This version addresses set of comments, but namely is still open on the volumes of queries and required infrastructure: -- It is expected that volumes for well-known name related queries are roughly SOMETHING, TBD. The infrastructure required to serve well- known name is SOMETHING, TBD. -- Help to assess those points would be very welcome - keeping in mind that the well-known name can have very long time-to-live value. There is still plenty of time to do -04 version, so please give feedback:) Diff is here: http://tools.ietf.org/rfcdiff?url2=draft-ietf-behave-nat64-discovery-heurist ic-03 Best regards, Teemu > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of ext internet-drafts@ietf.org > Sent: 14. lokakuuta 2011 12:55 > To: i-d-announce@ietf.org > Cc: behave@ietf.org > Subject: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic- > 03.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-03.txt > Pages : 8 > Date : 2011-10-14 > > 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 well-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-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-nat64-discovery- > heuristic-03.txt > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave ------=_NextPart_000_0073_01CC8A73.7ACF2650 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOuzCCAzYw ggIeoAMCAQICBDpVqdkwDQYJKoZIhvcNAQEFBQAwKTEOMAwGA1UEChMFTm9raWExFzAVBgNVBAMT Dk5va2lhICBSb290IENBMB4XDTAxMDEwNTExMDUwNVoXDTE2MDEwMjExMDUwNVowKTEOMAwGA1UE ChMFTm9raWExFzAVBgNVBAMTDk5va2lhICBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsrTy8gLmr4LYvp0khVUVHw7ascdl+Cjr+yI5MlZ6J/U6Qsvkiqthgqq8rPcLV0P1 92TfBr27VgKEeCaZe0icS1jC2spM/wRv3j2WxdkKxb9kDJtuCNJaRBqvi5vGTHB15nmEmKuL5f3i rAxeHqPjgS496oWcudzFT1e7Xrc/gWGFYd72+/ykIFXjWOMZv6QpxD8x1hLPyh2YVXRk9U7N7pvm RQNX29g4SCFJY2BBIa5JPlwIF8Nc9IePaC/E/2M4tGMtiOOZlm99EoL7N0hJZtFSvUwdCBud/viH 4DgsKGjNkNKi6pAHc9IaXB6tIykcoYp+L+oe/3+cuEJaCj1EKwIDAQABo2YwZDASBgNVHRMBAf8E CDAGAQH/AgEEMB0GA1UdDgQWBBSNjfefoQ0AITLvqe0iruA79NB9sDAfBgNVHSMEGDAWgBSNjfef oQ0AITLvqe0iruA79NB9sDAOBgNVHQ8BAf8EBAMCAYYwDQYJKoZIhvcNAQEFBQADggEBAIGEPql2 TALyKi/h1J+Mh5XolAtYppcSOLMtBkoA7ZovGBDNvl0VbZs8AAojJqkUoWBB+L6DKyl/jKhNfKcu rWRGRyj7pnbxrKLsI3gmWNWkyo2b60wJwe9fqPD5ZQy3oEiMit9l0Ba6il/k2GqYopUCNMa7mfeb E2LeBy5ChYMiCi97UQSJvAdzEYylTJw8Awc6AiM2Ve5N+XxsmKgNf/2A/5IJ3EZZ+wFRmkI4062A oNU302rqAt0HH88jzoUF4AfYHWl6HpYhGXFbcX44rHINyPmFBRxLYIFJ6ZWUr/mXpL/e6rqFtNWO kV6UoJND7OVZkbLh7F1+lcqXRU8TPBMwggOHMIICb6ADAgECAgRBtbHpMA0GCSqGSIb3DQEBBQUA MCkxDjAMBgNVBAoTBU5va2lhMRcwFQYDVQQDEw5Ob2tpYSAgUm9vdCBDQTAeFw0wNjAzMzAwOTU3 MTFaFw0xNjAxMDIxMTA1MDVaMDMxCzAJBgNVBAYTAkZJMQ4wDAYDVQQKEwVOb2tpYTEUMBIGA1UE AxMLTm9raWEgQkkgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDtFCg3QEjSCg6T IUxoWsNwELh8bBNiUQPCPmg8c2DHQYXWWCSCMb+S0Fvh1qqI1xt+XnzyFq+5eqzGzDj4UaBcG+d9 qxrCFly8sHyoPTryyPrR0EI2UUDWwfS6ojhqgwghRqo8G38TjFusyBtLub/5L6yvWYSOHD+JcB+q VM2fbkArPYK4Ydv8WG/DbHjGn0gKq0zwpVZKI/gCK/QALYvte02NXseqvY9/GOyLtjy3Z8erFv71 KKTq+gxI/7DK55pJf3PoD+kT4kyGm6EF9DTdK4ojMdar17uyX0IOZz/4vkkF0d+60nmnLX63FJPA jUyB0HUNJ32NXDo9UsM38aoNAgMBAAGjgawwgakwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAI MAYGBFUdIAAwDgYDVR0PAQH/BAQDAgGGMFQGA1UdIwRNMEuAFI2N95+hDQAhMu+p7SKu4Dv00H2w oS2kKzApMQ4wDAYDVQQKEwVOb2tpYTEXMBUGA1UEAxMOTm9raWEgIFJvb3QgQ0GCBDpVqdkwHQYD VR0OBBYEFKcksD7Fg+8EDlB2Sxgy58pW0Sy6MA0GCSqGSIb3DQEBBQUAA4IBAQAC3lEUplDlVNOT Pjz/XFezXx2bV2XbCFindhA3F815Egi55H6/cYezEjoP4QLNEGGl2I3aLvkn5A0T8I4pbiFPhIiu B/frbbGg6k6GjQLe/bFQ8F1mAOOR+GyneKZFPfzaRV0jiIR9QqnMXTf8RvKkCJyFj10MZVsLIy/Y uBkzeP3JhzDhUdtPfwmJN6ZbIhH5uR/2BwAGtgQknb8WX3I4wnhWtMUxB8XmayayYs8qWYeIiVkI FV+sLTkWUWVvvKUjyakBpbAW2vUP84DYsJ8TL1YefNjf/nIOByMcORLuV/1gPjyv00qJbcB59AA+ iXe3zIo8QNcgXG0uPQQFmrGDMIID5DCCAsygAwIBAgIQMH5apak8lEy6LmLlLsJy8TANBgkqhkiG 9w0BAQUFADAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJ IENBMB4XDTExMDkwNjA1NTIwNFoXDTE0MDkwNjA1NTIwNFowVjEOMAwGA1UECgwFTm9raWExDzAN BgNVBAsMBlBlb3BsZTEYMBYGCgmSJomT8ixkAQEMCDEwMDI0Njc2MRkwFwYDVQQDDBBTYXZvbGFp bmVuIFRlZW11MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAshEsmw6Yiz6XWX26oF+I s5fsfE1OfCjOelclmtqCiIgXND5klkNOBs2d4ZGzgD9mN+XnTZnOTh249c2WxPBugf12DCcDmBAJ gL+VuWUJVBTE5NRchm/O8nZnZsRFst+gAC9/Juykh4+EYewZ7QbpnlwW7hNpj8eH+rMr+OZHKzdp KTftgVjmuF4JJ/cPMQUjL8SuGj+zBW6IWPOZdqkEMtf7Pr8kkYbZsh0SgJ0ceRHZ7Uc06mB/y+C1 UnJPxehTTdu8tpCjdzXgBw/H2uuW1J3qdHbCfbuDILql8V8RiZKubcZLhdsD3Jvj8qK0DGWBJa6x p90q5p3pLE8LvAeCgQIDAQABo4HQMIHNMA4GA1UdDwEB/wQEAwIEMDAfBgNVHSMEGDAWgBSnJLA+ xYPvBA5QdksYMufKVtEsujAZBgNVHSAEEjAQMA4GDCsGAQQBXgExBgEHAzA5BgNVHR8EMjAwMC6g LKAqhihodHRwOi8vY3JsLm5va2lhLmNvbS9Ob2tpYSUyMEJJJTIwQ0EuY3JsMCUGA1UdEQQeMByB GnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBQTRzvZsgmQrAGCeuzdHTGAC6Jg UzANBgkqhkiG9w0BAQUFAAOCAQEACmPVsdi07pjK5gDa+W5JlE2C74kVVsB8alBqfioYeR5At2FG B7sua4Dz5H7TJMpZ1jYFeI+zjexD5f+beY2IlV15lMoWD+5e38QlLYjwfe2LAyvdzBKXW0e0U6Bt p78ft4gyVak1X+Db+ebR+FNHUOMNhm+yK3w9sy5ZQzBFusIx4OgxGvcZhyhmd9WjipSTalgPwgqV Ju2aPADCG++OEXmgEWRLsR4yNopkgK4ftVqrN5uUtLs83qdeXTRcNRiET1IOx5zmYFZ6q3gjKIx5 iyuxcDeYas93vVHUcaRRYpsoby5CHq7Z/j/TQhtqO/knWuxLFFiCUgdGKMKrRkg29DCCBAowggLy oAMCAQICEQCBvi+p+bA/dBtBtybwA6YYMA0GCSqGSIb3DQEBBQUAMDMxCzAJBgNVBAYTAkZJMQ4w DAYDVQQKEwVOb2tpYTEUMBIGA1UEAxMLTm9raWEgQkkgQ0EwHhcNMTEwOTA2MDU1MDM0WhcNMTMw OTA1MDU1MDM0WjBWMQ4wDAYDVQQKDAVOb2tpYTEPMA0GA1UECwwGUGVvcGxlMRgwFgYKCZImiZPy LGQBAQwIMTAwMjQ2NzYxGTAXBgNVBAMMEFNhdm9sYWluZW4gVGVlbXUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDFPmbRVwuo52v+h6xnQUqokAx2xsHjmPBniEkzgtgBNJsFi838ATEg 1zsx+VotoJg7hMijcrQfpTAgW6gpLGnlmw5QQswrNK1zleOHb4pA5JguU3WhVKFkAH/6/2EU2k/9 m8Pb/gwP55cYg80R6fRmbdsWKhseXF/1isW/rJcWLmIYDg/rXfo3ixqtT9MroAMiuoXnb0ij1L2d Jj64LDp3Ld8Jo0qZzk3Fj4apo8PBd8eAH6HloVBJkxQcwAnv561A+Xi1GHZ2mafRYJGO+1uBDwyd g/8ybEXXA4MKo8lPKjBebYBUFvz80DBA/Lq74UysXkG23BSulcG4xQSYGlyzAgMBAAGjgfUwgfIw HwYDVR0jBBgwFoAUpySwPsWD7wQOUHZLGDLnylbRLLowGQYDVR0gBBIwEDAOBgwrBgEEAV4BMQYB BgQwOQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5ub2tpYS5jb20vTm9raWElMjBCSSUyMENB LmNybDAjBgNVHSUEHDAaBggrBgEFBQcDAgYEVR0lAAYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgeA MCUGA1UdEQQeMByBGnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBTGhbTJF0EX iagjymQo6GIuSQeRVDANBgkqhkiG9w0BAQUFAAOCAQEAqai6TxZ/BlMHZIhJNPriBPXkQhUlBkGA buJZ5sVm1HIQhWN8elZKjjJdHi1qWEKhMg7yHjEMZsyV8XAZzK0UnOqkpUnt+jnVkNZ9O7/jRtyK f4WUtq5jErc8Hlv4bbGFRHk1T7AuLLE52r1lYOdmoibnQp03QtlDvHUNa68G7jvzThJhieB7U1xh vH3yy0ktaVnWEgAylqf9yIUFjnqau5R6cE1Xo57IYPk/KitX0YF+OigEI/bOQVMi+fze93ZsAOJv /z6g/NGemvUgl5YSdX0uPQK6kEHf/sp/nZyUWWQ7OjtVSqkq2YuYEueQFxTfafl+78GWqgm6W/Bl 32laYzGCAuswggLnAgEBMEgwMzELMAkGA1UEBhMCRkkxDjAMBgNVBAoTBU5va2lhMRQwEgYDVQQD EwtOb2tpYSBCSSBDQQIRAIG+L6n5sD90G0G3JvADphgwCQYFKw4DAhoFAKCCAXgwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTExMDE0MTAxNjI3WjAjBgkqhkiG9w0B CQQxFgQUIa1FAdyA0Nm0ArKcJbBt2eNOAHMwVgYJKwYBBAGCNxAEMUkwRzAzMQswCQYDVQQGEwJG STEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLx MFgGCyqGSIb3DQEJEAILMUmgRzAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNV BAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLxMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMA0GCSqGSIb3DQEBAQUABIIBAKqttaWhqEN77oHmobRo S20dCeRaduIPaw4a+DDCk86xQmvMJoQDb01eiUavYIFwghu9FzOECXYWbuDtK6boLwf6/9fUPmum 6apDRnvPrLAHZMC0OomlcY5r0kSAE3CAIv7Df/5T244zuVoxYffl9c142lPL5Gp1nfubZVSixKOf kI3Bw3eR4xiaaDppIpLqvz+2V3+7Cdb0Mo0ovNdQCPH5tdirJJRDrIyM1NjWZL8rl41K/kb5tHUO icmtCeuDA/IDA1BqaaPBtMVnolMBDvtLac2l9sdjZHirCJ9EIxOxP7Uf4JscYr7+bNfvom9ZB+2a nxxh3M7pP0hFMVfe0igAAAAAAAA= ------=_NextPart_000_0073_01CC8A73.7ACF2650-- From simon.perreault@viagenie.ca Sun Oct 16 05:19:39 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CBB621F8AAA for ; Sun, 16 Oct 2011 05:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXpg1NMqYjK9 for ; Sun, 16 Oct 2011 05:19:38 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 2F75721F8AA8 for ; Sun, 16 Oct 2011 05:19:38 -0700 (PDT) Received: from [192.168.1.149] (modemcable065.20-22-96.mc.videotron.ca [96.22.20.65]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 3518921F46 for ; Sun, 16 Oct 2011 08:19:37 -0400 (EDT) Message-ID: <4E9ACBD8.9000307@viagenie.ca> Date: Sun, 16 Oct 2011 08:19:36 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: behave@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [BEHAVE] NAT64 in OpenBSD 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, 16 Oct 2011 12:19:39 -0000 FYI, Our NAT64 patch has been committed to OpenBSD's CVS repository. This means it should be part of official release 5.1. Commit logs here: http://marc.info/?l=openbsd-cvs&m=131853039828163 http://marc.info/?l=openbsd-cvs&m=131853093528864 http://marc.info/?l=openbsd-cvs&m=131853084528755 Our NAT64 patches for OpenBSD and Linux, along with DNS64 patches, are here: http://ecdysis.viagenie.ca/ Simon From bschlies@cisco.com Sun Oct 16 13:50: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 14F1121F8593 for ; Sun, 16 Oct 2011 13:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJb4F7G2nJtI for ; Sun, 16 Oct 2011 13:50:45 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id D5A3221F8500 for ; Sun, 16 Oct 2011 13:50:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=2186; q=dns/txt; s=iport; t=1318798244; x=1320007844; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Y8s4CEK4z348MEPURZNZM5giPmNAJd/3u7kPrwBh2DA=; b=A8L6dbC++CuXwau8/ImsNxQjm8R5Jpv4jY7eVosNtyvfr8piwsdbi7Y1 hTVio3bjHPk50gUKk0d3ettkxAdP0Y1xGek6ddGeEN+p1sq1Nrb+gbCH/ O+R2HdBUVJJr0VuECJdIIaoA689qXDRVsYXlbAIgBlhphZCYB2i78QuS8 E=; X-IronPort-AV: E=Sophos;i="4.69,354,1315180800"; d="scan'208";a="8188619" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 16 Oct 2011 20:50:44 +0000 Received: from [10.240.95.19] (sjc-vpn5-132.cisco.com [10.21.88.132]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9GKoi36001052; Sun, 16 Oct 2011 20:50:44 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Benson Schliesser In-Reply-To: <02d001cc8a03$817f99a0$847ecce0$@com> Date: Sun, 16 Oct 2011 15:50:44 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <420AF2F1-9E7E-4745-BD34-FCBCA8455871@cisco.com> References: <02d001cc8a03$817f99a0$847ecce0$@com> To: Dan Wing X-Mailer: Apple Mail (2.1084) Cc: behave@ietf.org Subject: Re: [BEHAVE] CGN Requirements: logging (draft-ietf-behave-lsn-requirements) 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, 16 Oct 2011 20:50:46 -0000 On Oct 13, 2011, at 6:54 PM, Dan Wing wrote: > The current text in > = http://tools.ietf.org/html/draft-ietf-behave-lsn-requirements-03#section-4= > implies that a CGN needs to log destinations. >=20 > As we all know, there are two significant drawbacks to destination=20 > logging: >=20 > * if more than one user is visiting the same site, destination > logging doesn't help distinguish between those users. Source port > logging does. The corollary is that destination logging helps > identify a user visiting an unpopular server when that unpopular > server is not logging source port. > * destination logging creates privacy issues. >=20 > To align draft-ietf-behave-lsn-requirements with RFC6302 ("Logging > Recommendations for Internet-Facing Servers"), should > draft-ietf-behave-lsn-requirements instead state that destination > logging SHOULD NOT be performed, and recommend that a CGN simply > do source port logging in anticipation of servers following=20 > RFC6302? I don't think draft-ietf-behave-lsn-requirements should specify one way = or the other. I do think that it should discuss the topic in "MAY" = terms, and give appropriate cautions. Clearly, logging destination along with translated and original source = address + port would reveal customer behavior in some detail. Logging = only the translated and original address + port would be adequate for = law enforcement requests targeting specific historical transactions. = Logging only destination (and nothing else, or decoupled from source = logging) might be informative from a demographic perspective, but has a = smaller privacy impact. While I personally don't find the privacy implications very appealing, I = know that this kind of intelligence is already gathered by some ISPs. = (With DPI tools etc.) There may be law enforcement and/or business = reasons that they want this, and making the IETF document take an = opposition position would only cause problems - vendors will still = produce what SP customers want, resulting in a situation where CGN = products are frequently not compliant with this document. Cheers, -Benson From dwing@cisco.com Mon Oct 17 15:49:50 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2157C11E80A6 for ; Mon, 17 Oct 2011 15:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.111 X-Spam-Level: X-Spam-Status: No, score=-105.111 tagged_above=-999 required=5 tests=[AWL=1.488, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQO6kr7efYYA for ; Mon, 17 Oct 2011 15:49:49 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 6B96811E8098 for ; Mon, 17 Oct 2011 15:49:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2994; q=dns/txt; s=iport; t=1318891789; x=1320101389; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=J+0zZoOSVTTSJ8RnL070vXli7ouTg8B0hF7NGbflKP8=; b=LrNIaV0wgG+P3P0w71XVrg430ez9YzBB4eNIrow+wnevt5VdPXFs0ad+ KgfkzxNxW5wCIjfEwuavzHJD/ml2alqDZUo2GrFiEyNfoEvAevmw7QwiQ kDxHMirSnXwWmFEkkWwguhJ/6lLigL8X1MAiWlC7rvVsIyexxlZodS6vy o=; X-IronPort-AV: E=Sophos;i="4.69,362,1315180800"; d="scan'208";a="8448443" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 17 Oct 2011 22:49:49 +0000 Received: from dwingWS ([10.32.240.197]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9HMnnfS009644; Mon, 17 Oct 2011 22:49:49 GMT From: "Dan Wing" To: "'Benson Schliesser'" References: <02d001cc8a03$817f99a0$847ecce0$@com> <420AF2F1-9E7E-4745-BD34-FCBCA8455871@cisco.com> In-Reply-To: <420AF2F1-9E7E-4745-BD34-FCBCA8455871@cisco.com> Date: Mon, 17 Oct 2011 15:49:48 -0700 Message-ID: <023901cc8d1f$133206d0$39961470$@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: AcyMRUZ7nbPuCMYqRQqMiIfVX78csQA2WCtg Content-Language: en-us Cc: behave@ietf.org Subject: Re: [BEHAVE] CGN Requirements: logging (draft-ietf-behave-lsn-requirements) 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, 17 Oct 2011 22:49:50 -0000 > -----Original Message----- > From: Benson Schliesser [mailto:bschlies@cisco.com] > Sent: Sunday, October 16, 2011 1:51 PM > To: Dan Wing > Cc: behave@ietf.org > Subject: Re: [BEHAVE] CGN Requirements: logging (draft-ietf-behave-lsn- > requirements) > > > On Oct 13, 2011, at 6:54 PM, Dan Wing wrote: > > > The current text in > > http://tools.ietf.org/html/draft-ietf-behave-lsn-requirements- > 03#section-4 > > implies that a CGN needs to log destinations. > > > > As we all know, there are two significant drawbacks to destination > > logging: > > > > * if more than one user is visiting the same site, destination > > logging doesn't help distinguish between those users. Source port > > logging does. The corollary is that destination logging helps > > identify a user visiting an unpopular server when that unpopular > > server is not logging source port. > > * destination logging creates privacy issues. > > > > To align draft-ietf-behave-lsn-requirements with RFC6302 ("Logging > > Recommendations for Internet-Facing Servers"), should > > draft-ietf-behave-lsn-requirements instead state that destination > > logging SHOULD NOT be performed, and recommend that a CGN simply > > do source port logging in anticipation of servers following > > RFC6302? > > I don't think draft-ietf-behave-lsn-requirements should specify one way > or the other. I do think that it should discuss the topic in "MAY" > terms, and give appropriate cautions. > > Clearly, logging destination along with translated and original source > address + port would reveal customer behavior in some detail. Logging > only the translated and original address + port would be adequate for > law enforcement requests targeting specific historical transactions. It seems that is the core of the requirement created by IPv4 address sharing, especially in light of RFC6302 (Logging Recommendations for Internet-Facing Servers). > Logging only destination (and nothing else, or decoupled from source > logging) might be informative from a demographic perspective, but has a > smaller privacy impact. > > While I personally don't find the privacy implications very appealing, > I know that this kind of intelligence is already gathered by some ISPs. > (With DPI tools etc.) There may be law enforcement and/or business > reasons that they want this, and making the IETF document take an > opposition position would only cause problems - vendors will still > produce what SP customers want, resulting in a situation where CGN > products are frequently not compliant with this document. Considering such a requirement exists in some places (today) without CGN, the deployment of a CGN would not affect those network's requirements to do destination logging -- they would still be required to log destination. I don't want to conflate "logging destinations is needed in Country X" with "CGN requires logging destinations". -d From bschlies@cisco.com Tue Oct 18 11:23: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 227BC21F8B88 for ; Tue, 18 Oct 2011 11:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.266 X-Spam-Level: X-Spam-Status: No, score=-5.266 tagged_above=-999 required=5 tests=[AWL=1.333, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JyaFlX+D49xl for ; Tue, 18 Oct 2011 11:23:54 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 45D6021F8B5B for ; Tue, 18 Oct 2011 11:23:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=2494; q=dns/txt; s=iport; t=1318962230; x=1320171830; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=dMuBdfjlaeZdsW8Q9TSZbqAHwf6hOU9vLJJYJXCnYNQ=; b=hTpU3h/+7haui7UQvE6ToomM3UlYcBxmTuKzQiWQ/mAw855zwjohmdos rOy63OjPIWKGakzaIEGJbpseJBFCXUSOrGd8dUqIQ+yTrvzp74PBWI5o3 PgTSMJeGyNt8IEZLcVraDgzsdm/PYchR5+P5YzeD3mZl1oJmMe07oyPB3 Y=; X-IronPort-AV: E=Sophos;i="4.69,366,1315180800"; d="scan'208";a="8655463" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 18 Oct 2011 18:23:49 +0000 Received: from [10.22.239.74] (sjc-vpn4-1233.cisco.com [10.21.84.208]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p9IINm7o014824; Tue, 18 Oct 2011 18:23:48 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Benson Schliesser In-Reply-To: <023901cc8d1f$133206d0$39961470$@com> Date: Tue, 18 Oct 2011 11:23:49 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5A453A14-04D0-4DA5-A7AC-970D7579F4DE@cisco.com> References: <02d001cc8a03$817f99a0$847ecce0$@com> <420AF2F1-9E7E-4745-BD34-FCBCA8455871@cisco.com> <023901cc8d1f$133206d0$39961470$@com> To: "Dan Wing" X-Mailer: Apple Mail (2.1084) Cc: behave@ietf.org Subject: Re: [BEHAVE] CGN Requirements: logging (draft-ietf-behave-lsn-requirements) 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, 18 Oct 2011 18:23:57 -0000 On Oct 17, 2011, at 3:49 PM, Dan Wing wrote: >>> To align draft-ietf-behave-lsn-requirements with RFC6302 ("Logging >>> Recommendations for Internet-Facing Servers"), should >>> draft-ietf-behave-lsn-requirements instead state that destination >>> logging SHOULD NOT be performed, and recommend that a CGN simply >>> do source port logging in anticipation of servers following >>> RFC6302? >>=20 >> I don't think draft-ietf-behave-lsn-requirements should specify one = way >> or the other. I do think that it should discuss the topic in "MAY" >> terms, and give appropriate cautions. >>=20 >> Clearly, logging destination along with translated and original = source >> address + port would reveal customer behavior in some detail. = Logging >> only the translated and original address + port would be adequate for >> law enforcement requests targeting specific historical transactions. >=20 > It seems that is the core of the requirement created by IPv4 address > sharing, especially in light of RFC6302 (Logging Recommendations for=20= > Internet-Facing Servers). Yes, and I agree that logging translated and original source address + = port is something that might be a SHOULD or MUST requirement. >> Logging only destination (and nothing else, or decoupled from source >> logging) might be informative from a demographic perspective, but has = a >> smaller privacy impact. >>=20 >> While I personally don't find the privacy implications very = appealing, >> I know that this kind of intelligence is already gathered by some = ISPs. >> (With DPI tools etc.) There may be law enforcement and/or business >> reasons that they want this, and making the IETF document take an >> opposition position would only cause problems - vendors will still >> produce what SP customers want, resulting in a situation where CGN >> products are frequently not compliant with this document. >=20 > Considering such a requirement exists in some places (today) without > CGN, the deployment of a CGN would not affect those network's = requirements > to do destination logging -- they would still be required to log=20 > destination. I don't want to conflate "logging destinations is needed=20= > in Country X" with "CGN requires logging destinations". I agree, we should not conflate these topics. That's why the = requirements document should avoid "SHOULD NOT" or "MUST NOT" language, = with regard to destination logging. Cheers, -Benson From mohamed.boucadair@orange.com Fri Oct 21 08:13:45 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 6A8921F0C53 for ; Fri, 21 Oct 2011 08:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.074 X-Spam-Level: X-Spam-Status: No, score=-3.074 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F+e+Xc2UfhZQ for ; Fri, 21 Oct 2011 08:13:44 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id A2F6511E80A6 for ; Fri, 21 Oct 2011 08:13:44 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 0DD44264573 for ; Fri, 21 Oct 2011 17:13:43 +0200 (CEST) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 45BAC27C054; Fri, 21 Oct 2011 17:13:39 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Fri, 21 Oct 2011 17:13:38 +0200 From: To: "'behave@ietf.org'" Date: Fri, 21 Oct 2011 17:13:37 +0200 Thread-Topic: Implementation & Preliminary Test Results of HOST_ID TCP Option (draft-abdo-hostid-tcpopt-implementation) Thread-Index: AcyQAPx0WWhhKoGpRre5/7mFh/5VRQAAOuMQ Message-ID: <94C682931C08B048B7A8645303FDC9F35A2E6EFDDC@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.10.21.130315 Cc: ABDO Elie RD-CORE , QUEIROZ Jaqueline RD-CORE Subject: [BEHAVE] Implementation & Preliminary Test Results of HOST_ID TCP Option (draft-abdo-hostid-tcpopt-implementation) 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, 21 Oct 2011 15:13:45 -0000 Dear all, We have submitted the following I-D.=20 Title : HOST_ID TCP Options: Implementation & Preliminary Te= st Results Author(s) : Elie Abdo Mohamed Boucadair Jaqueline Queiroz Filename : draft-abdo-hostid-tcpopt-implementation-00.txt Pages : 15 Date : 2011-10-21 This memo documents the implementation of the HOST_ID TCP Options. It also discusses the preliminary results of the tests that have been conducted to assess the technical feasibility of the approach as well as its scalability. Several HOST_ID TCP options have been implemented and tested. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-abdo-hostid-tcpopt-implementation= -00.txt Comments, questions, suggestions, etc. are more than welcome. Cheers, Med = From brian.e.carpenter@gmail.com Fri Oct 21 17:50: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 80B541F0C44 for ; Fri, 21 Oct 2011 17:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.379 X-Spam-Level: X-Spam-Status: No, score=-103.379 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uwjd3haHRBAe for ; Fri, 21 Oct 2011 17:50:13 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id DBDF51F0C34 for ; Fri, 21 Oct 2011 17:50:12 -0700 (PDT) Received: by iabn5 with SMTP id n5so5893129iab.31 for ; Fri, 21 Oct 2011 17:50:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=TnYhN82jH9A3b55aVRmW/SNZJGRwdLkmUEI5iQPW5ds=; b=WFdSduf9KIYp7Amu48QNdkKxQe1nCxQRnEkVyezKcM1I/u+Eec/H453ol+zKYo5MQX ox9p1Z2iRoPSMYOMnYPsxTxl9V6ECWbyoIXANCzHBPran3rptvSq2+Fa9/64a7WNXz/a 3hoEcJ+IobzbP4O1wRqIDsGE3m3ysX9zKl1rE= Received: by 10.231.6.10 with SMTP id 10mr6195728ibx.76.1319244609632; Fri, 21 Oct 2011 17:50:09 -0700 (PDT) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id n30sm37575964ibl.4.2011.10.21.17.50.06 (version=SSLv3 cipher=OTHER); Fri, 21 Oct 2011 17:50:08 -0700 (PDT) Message-ID: <4EA2133A.7070109@gmail.com> Date: Sat, 22 Oct 2011 13:50:02 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: behave@ietf.org References: <20111017221734.10709.82660.idtracker@ietfa.amsl.com> In-Reply-To: <20111017221734.10709.82660.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] I-D Action: draft-wing-behave-dhcpv6-reconfigure-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: Sat, 22 Oct 2011 00:50:13 -0000 I have a basic question. Why does this draft define a 'normal' DNS server as one having an IPv4-mapped IPv6 address? That seems like a completely *abnormal* DNS server for a dual stack host. A dual stack host should normally have a DNS server with a regular IPv6 address that will return both A and AAAA records if they exist. Normally the server will be dual stacked anyway, and will return exactly the same response whether the query arrives via v4 or v6. A DNS server which only has an IPv4 address will also return A and AAAA records if they exist, so there is absolutely no difference as far as the dual stack host is concerned anyway. So what is the point in using the IPv4-mapped address? Regards Brian On 2011-10-18 11:17, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : DHCPv6 Dynamic Re-Configuration > Author(s) : Dan Wing > Tirumaleswar Reddy > Prashanth Patil > Filename : draft-wing-behave-dhcpv6-reconfigure-00.txt > Pages : 10 > Date : 2011-10-17 > > Some networks are expected to support IPv4-only, dual-stack, and > IPV6-only hosts at the same time. This makes prioritizing the DNS > servers for hosts tricky due to a heterogeneous mix of protocol > stacks causing optimal behavior to occur only when the host stack re- > initializes. The networks infrastructure is usually well equipped to > be aware of single/dual-stack nature of hosts. This specification > extends DHCPv6 so that the DHCPv6 Relay Agent can dynamically > influence the priority of DNS servers provided to the host, so that > the host can use the optimal DNS server for resolution. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-wing-behave-dhcpv6-reconfigure-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-wing-behave-dhcpv6-reconfigure-00.txt > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From Ray.Bellis@nominet.org.uk Mon Oct 24 01:58: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 3381421F8CAA for ; Mon, 24 Oct 2011 01:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.859 X-Spam-Level: X-Spam-Status: No, score=-9.859 tagged_above=-999 required=5 tests=[AWL=0.740, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dp+go-8FSrLd for ; Mon, 24 Oct 2011 01:58:27 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by ietfa.amsl.com (Postfix) with ESMTP id 4F02421F8BBB for ; Mon, 24 Oct 2011 01:58:26 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:Subject: Thread-Topic:Thread-Index:Date:Message-ID:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version; b=csR7hPQ9eRkLhLtaHTMW+7MLmCJFGQ6MyfllxJlQTm0FwdJKTFtwh/hi RYN6yEbZpe7NxDaCvLRkyA3oeC9SFMn3sYNB/oqT2mE5EReHNRTNoe/x6 6tqEj+lc6j8MHuZ; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1319446707; x=1350982707; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20FW:=20New=20Version=20Notification=20for=0D =0A=20draft-bellis-behave-natpresent-00.txt=20|Date:=20Mo n,=2024=20Oct=202011=2008:58:24=20+0000|Message-ID:=20|To:=20 "behave@ietf.org"=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |Content-ID:=20; bh=qrcjQDXUZMeNwLmapm6Zl4fuiY+rtIfhKx2GDSi4l3E=; b=fgSX4vQPTZ+0ZEpRsOrt5ET2eO7TgTvo2ATfnT1wQZhSu5/SAXq+5OhH a5UuSSwhLT2HZpg7pPsYK9Ul/sjpOa2A0UnxbCxLkRHQjU80VlIErEJot SRA8tEUV9ktpqwA; X-IronPort-AV: E=Sophos;i="4.69,397,1315177200"; d="scan'208";a="29143308" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx4.nominet.org.uk with ESMTP; 24 Oct 2011 09:58:25 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%19]) with mapi; Mon, 24 Oct 2011 09:58:25 +0100 From: Ray Bellis To: "behave@ietf.org" Thread-Topic: New Version Notification for draft-bellis-behave-natpresent-00.txt Thread-Index: AQHMkisW33J5eJjMZkWSayG0NucZ2g== Date: Mon, 24 Oct 2011 08:58:24 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [BEHAVE] FW: New Version Notification for draft-bellis-behave-natpresent-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, 24 Oct 2011 08:58:28 -0000 Forwarded for the group's information: The primary intent is for Layer 7 applications to be able to receive explic= it in-band notification of modifications at L3/L4. --8<--8<-- Subject: New Version Notification for draft-bellis-behave-natpresent-00.txt A new version of I-D, draft-bellis-behave-natpresent-00.txt has been succes= sfully submitted by Ray Bellis and posted to the IETF repository. Filename: draft-bellis-behave-natpresent Revision: 00 Title: Signalling the Presence of NAT Creation date: 2011-10-23 WG ID: Individual Submission Number of pages: 7 Abstract: End-to-end applications have difficulty distinguishing between packets that have been passed through a Network Address Translator (NAT) and packets that have been passed along a clear end-to-end path. We propose mechanisms for IPv4 and IPv6 whereby NAT devices explicitly signal their operation as a means of allowing applications to distinguish the presence of otherwise undetected NATs in the end- to-end path. --8<--8<-- Ray From xing@cernet.edu.cn Mon Oct 24 03:26: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 87EE121F8CBF for ; Mon, 24 Oct 2011 03:26:41 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Thhn1t4M3hIS for ; Mon, 24 Oct 2011 03:26:41 -0700 (PDT) Received: from cernet.edu.cn (cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with SMTP id 7805721F8C1E for ; Mon, 24 Oct 2011 03:26:40 -0700 (PDT) Received: from [127.0.0.1]([202.38.102.1]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm324ea54cd9; Mon, 24 Oct 2011 18:26:38 +0800 Message-ID: <4EA53D5B.20106@cernet.edu.cn> Date: Mon, 24 Oct 2011 18:26:35 +0800 From: Xing Li User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; zh-CN; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15 MIME-Version: 1.0 To: behave-chairs@tools.ietf.org Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: vlqjRS1B Cc: Behave WG Subject: Re: [BEHAVE] presentations at IETF82 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, 24 Oct 2011 10:26:41 -0000 Hi, Dan and Dave, We request a slot for presentation in BEHAVE at IETF82. - topic title: Dual stateless translation (dIVI) and address format extension - presenter's name: Xing Li - Internet Draft filename(s): https://datatracker.ietf.org/doc/draft-xli-behave-divi/ https://datatracker.ietf.org/doc/draft-bcx-behave-address-fmt-extension/ - time requested: 15 min Thank you very much! Regards, xing, congxiao > We requested a 2 hour slot for BEHAVE. > > If you would like to present in BEHAVE at IETF82, please send to > behave-chairs@tools.ietf.org: > - topic title > - presenter's name > - Internet Draft filename(s) > - time requested > > We will give priority to: > 1. working group items > 2. items actively discussed on the mailing list > 3. new topics > > Please send the request by October 24th, which is also the cutoff > date for initial Internet Drafts (-00). > > -Dan and Dave > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > From simon.perreault@viagenie.ca Mon Oct 24 05:27: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 0EDF521F8BD8 for ; Mon, 24 Oct 2011 05:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y22+TXMorr9X for ; Mon, 24 Oct 2011 05:27:02 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 75F8F21F8C18 for ; Mon, 24 Oct 2011 05:27:02 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:21d:60ff:fed7:e732]) by jazz.viagenie.ca (Postfix) with ESMTPSA id BC73E20D23 for ; Mon, 24 Oct 2011 08:27:01 -0400 (EDT) Message-ID: <4EA55995.6010808@viagenie.ca> Date: Mon, 24 Oct 2011 08:27:01 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110720 Thunderbird/5.0 MIME-Version: 1.0 To: behave@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.2.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] FW: New Version Notification for draft-bellis-behave-natpresent-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, 24 Oct 2011 12:27:03 -0000 Before I comment on this draft, I would like the authors to confirm that this is not a joke. I'm detecting high levels of humour and sarcasm, and trace amounts of craziness. :) Simon On 2011-10-24 04:58, Ray Bellis wrote: > Forwarded for the group's information: > > The primary intent is for Layer 7 applications to be able to receive explicit in-band notification of modifications at L3/L4. > > --8<--8<-- > Subject: New Version Notification for draft-bellis-behave-natpresent-00.txt > > A new version of I-D, draft-bellis-behave-natpresent-00.txt has been successfully submitted by Ray Bellis and posted to the IETF repository. > > Filename: draft-bellis-behave-natpresent > Revision: 00 > Title: Signalling the Presence of NAT > Creation date: 2011-10-23 > WG ID: Individual Submission > Number of pages: 7 > > Abstract: > End-to-end applications have difficulty distinguishing between > packets that have been passed through a Network Address Translator > (NAT) and packets that have been passed along a clear end-to-end > path. We propose mechanisms for IPv4 and IPv6 whereby NAT devices > explicitly signal their operation as a means of allowing applications > to distinguish the presence of otherwise undetected NATs in the end- > to-end path. > > --8<--8<-- > > Ray > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From Ray.Bellis@nominet.org.uk Mon Oct 24 05:36:04 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C92421F8AA9 for ; Mon, 24 Oct 2011 05:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.941 X-Spam-Level: X-Spam-Status: No, score=-9.941 tagged_above=-999 required=5 tests=[AWL=0.658, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K0MbuQ4E9qKv for ; Mon, 24 Oct 2011 05:36:03 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by ietfa.amsl.com (Postfix) with ESMTP id 1C69621F8A62 for ; Mon, 24 Oct 2011 05:36:02 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: Content-ID:Content-Transfer-Encoding:MIME-Version; b=qG/tKsOH9symGWQ0+2+6i0UOQJj0jrUNWt+fk/2Jng+rCiJnApDZAlCn mVKZMcpMBdraFJw3QG+adLCcTSdDXlppsO8hbVBEWGx3L84hI4elkrHWd l+tG3uW0EdPhdxH; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1319459763; x=1350995763; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[BEHAVE]=20FW:=20New=20Version=20Notifi cation=20for=0D=0A=09draft-bellis-behave-natpresent-00.tx t|Date:=20Mon,=2024=20Oct=202011=2012:35:49=20+0000 |Message-ID:=20|To:=20Simon=20Perreault=20|CC:=20""=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable|Content-ID:=20<27d61403-9920-465b-96e1-c22dafa4 d723>|In-Reply-To:=20<4EA55995.6010808@viagenie.ca> |References:=20=0D=0A=20<4EA55995.6010808@viagenie.ca>; bh=FHfGBRs/PA7yqsSQ+CY1713hz/RkwsbB3cXYjgxyv80=; b=FYTnC8mlv0k4AwquIdHRJE3EkCu13Rm81eywczfN4/WYVHx5Wx8yaHz7 wyJlUwqsGbzZ3rki78RGYtNMZfz62D/X++JtquWdjaXMi/N4kBOXGn3e1 cyntiGAebBMDaH/; X-IronPort-AV: E=Sophos;i="4.69,398,1315177200"; d="scan'208";a="29148757" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx4.nominet.org.uk with ESMTP; 24 Oct 2011 13:35:50 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%19]) with mapi; Mon, 24 Oct 2011 13:35:49 +0100 From: Ray Bellis To: Simon Perreault Thread-Topic: [BEHAVE] FW: New Version Notification for draft-bellis-behave-natpresent-00.txt Thread-Index: AQHMkkhBHWt23XFa8Emugofxw6ZpKpWLXZeA Date: Mon, 24 Oct 2011 12:35:49 +0000 Message-ID: References: <4EA55995.6010808@viagenie.ca> In-Reply-To: <4EA55995.6010808@viagenie.ca> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <27d61403-9920-465b-96e1-c22dafa4d723> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [BEHAVE] FW: New Version Notification for draft-bellis-behave-natpresent-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, 24 Oct 2011 12:36:04 -0000 On 24 Oct 2011, at 13:27, Simon Perreault wrote: > Before I comment on this draft, I would like the authors to confirm that > this is not a joke. I'm detecting high levels of humour and sarcasm, and > trace amounts of craziness. >=20 > :) >=20 No, it is _not_ a joke. It _may_ well be crazy, but I figured we wouldn't know that until other peo= ple have had a chance to think about it ;-) Ray From simon.perreault@viagenie.ca Mon Oct 24 05:50: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 0721421F8C51 for ; Mon, 24 Oct 2011 05:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wVXAT9i+zg3 for ; Mon, 24 Oct 2011 05:50:04 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 0099B21F8C59 for ; Mon, 24 Oct 2011 05:50:01 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:21d:60ff:fed7:e732]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 6605521ED9; Mon, 24 Oct 2011 08:50:00 -0400 (EDT) Message-ID: <4EA55EF7.4010603@viagenie.ca> Date: Mon, 24 Oct 2011 08:49:59 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110720 Thunderbird/5.0 MIME-Version: 1.0 To: Ray Bellis References: <4EA55995.6010808@viagenie.ca> In-Reply-To: X-Enigmail-Version: 1.2.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [BEHAVE] FW: New Version Notification for draft-bellis-behave-natpresent-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, 24 Oct 2011 12:50:05 -0000 On 2011-10-24 08:35, Ray Bellis wrote: > On 24 Oct 2011, at 13:27, Simon Perreault wrote: >> Before I comment on this draft, I would like the authors to confirm that >> this is not a joke. I'm detecting high levels of humour and sarcasm, and >> trace amounts of craziness. > > No, it is _not_ a joke. Thanks. Here are some initial, high-level comments: I don't think this draft solves an existing problem. What applications need to know is *not* if there is a NAT in the path. They don't care. They especially don't care in cases where there are two NATs in the path where one reverses the other's mapping (yes it happens). What applications need to know is "what public IP address+port am I mapped to when I talk to XYZ". This is the piece of information that is needed to establish a direct peer-to-peer connection via a rendez-vous server. And the way to do that is the infamous STUN/TURN/ICE. It's complex because it needs to be. I think I'm looking for an answer to the following question: How should apps modify their behaviour when they see the evil bit? The draft says: 4. Application Processing Applications that receive a packet with a non-zero NAT Present option MUST assume that the IP header's source and destination address, the transport level source and destination ports and even the IP version value may have been altered by a NAT in the end-to-end path. What should the assume_nat() function I'm about to add to my app contain? Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From Ray.Bellis@nominet.org.uk Mon Oct 24 06:14: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 D761521F8C16 for ; Mon, 24 Oct 2011 06:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.707 X-Spam-Level: X-Spam-Status: No, score=-7.707 tagged_above=-999 required=5 tests=[AWL=-1.708, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8epOcunofC5b for ; Mon, 24 Oct 2011 06:14:49 -0700 (PDT) Received: from mx1.knowthenet.org.uk (mx1.knowthenet.org.uk [213.248.199.2]) by ietfa.amsl.com (Postfix) with ESMTP id CD86E21F8BEB for ; Mon, 24 Oct 2011 06:14:48 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: Content-ID:Content-Transfer-Encoding:MIME-Version; b=bhLKXXeAkviTqP0+dGvlq5pv/D3CPmRLs8G6MIORPpdKnjDIaJbDa8g3 wFA9PjsTSycSunJbwZ5cNa5TI+zvy67V19xx3jXkf3zTk97E8oFgWIyQg 0K+gW8Y1JmJsXYR; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1319462089; x=1350998089; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[BEHAVE]=20New=20Version=20Notification =20for=0D=0A=20draft-bellis-behave-natpresent-00.txt |Date:=20Mon,=2024=20Oct=202011=2013:14:46=20+0000 |Message-ID:=20|To:=20Simon=20Perreault=20|CC:=20"behave@ietf.org"=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable|Content-ID:=20<98a0ca94-549b-4cd9-b2e7-3c3b804f bc22>|In-Reply-To:=20<4EA55EF7.4010603@viagenie.ca> |References:=20=0D=0A=20<4EA55995.6010808@viagenie.ca>=0D=0A =20 =0D=0A=20<4EA55EF7.4010603@viagenie.ca>; bh=hOUOdUxY5ICUGthbJ4jHv2CX6xcNkbsuFgg6581o9l0=; b=GfQCD6JqF5gZToo4PA2pyE9n7kAGY/ylOdjmNmt1ZXB8mP/McJscprSg 1oBg70KEWLw4/NtNmw4fZ54/05V26IHZSAjCjEvK1JKsLhxIZo4X03NRl CV5pKxfEZOQ7W21; X-IronPort-AV: E=Sophos;i="4.69,398,1315177200"; d="scan'208";a="36123583" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx3.nominet.org.uk with ESMTP; 24 Oct 2011 14:14:47 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%19]) with mapi; Mon, 24 Oct 2011 14:14:47 +0100 From: Ray Bellis To: Simon Perreault Thread-Topic: [BEHAVE] New Version Notification for draft-bellis-behave-natpresent-00.txt Thread-Index: AQHMkk7mxcZnQH58iESbRvpOk5XY6Q== Date: Mon, 24 Oct 2011 13:14:46 +0000 Message-ID: References: <4EA55995.6010808@viagenie.ca> <4EA55EF7.4010603@viagenie.ca> In-Reply-To: <4EA55EF7.4010603@viagenie.ca> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-ID: <98a0ca94-549b-4cd9-b2e7-3c3b804fbc22> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] New Version Notification for draft-bellis-behave-natpresent-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, 24 Oct 2011 13:14:49 -0000 On 24 Oct 2011, at 13:49, Simon Perreault wrote: > I think I'm looking for an answer to the following question: > How should apps modify their behaviour when they see the evil bit? Who said "evil bit" ?! ;-) > The draft says: >=20 > 4. Application Processing >=20 > Applications that receive a packet with a non-zero NAT Present option > MUST assume that the IP header's source and destination address, the > transport level source and destination ports and even the IP version > value may have been altered by a NAT in the end-to-end path. >=20 > What should the assume_nat() function I'm about to add to my app contain? Whatever it wants, of course! As it happens, the original idea came to me as a way of allowing applicatio= ns to "prefer" end-to-end clear paths over paths that go through a CGN, i.e= . an extra piece of information for "Happy Eyeballs" algorithms. Over on v6ops certain operators were bemoaning that certain OS software fol= ks won't use V6 in preference to a V4 CGNed path if all else were equal, wh= ere "equal" is AFAIK only assessed based on RTT. The operators would rather have more V6 traffic than have everyone fill up = their CGNs. The alternative would be for them to introduce artificial dela= ys in their V4 CGN paths to ensure that V6 wins. This was actually propose= d on list!=20 This then, is a way to provide a second-order measure of "equality". There's plenty of other stuff too which Geoff can probably explain better t= han I can, but I expect he's asleep just now. Ray From simon.perreault@viagenie.ca Mon Oct 24 06:57: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 C533721F8C91 for ; Mon, 24 Oct 2011 06:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbVhxnPDVSGg for ; Mon, 24 Oct 2011 06:57:25 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 3043B21F8D5B for ; Mon, 24 Oct 2011 06:57:25 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:21d:60ff:fed7:e732]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 939F720D1D; Mon, 24 Oct 2011 09:57:24 -0400 (EDT) Message-ID: <4EA56EC4.8030101@viagenie.ca> Date: Mon, 24 Oct 2011 09:57:24 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110720 Thunderbird/5.0 MIME-Version: 1.0 To: Ray Bellis References: <4EA55995.6010808@viagenie.ca> <4EA55EF7.4010603@viagenie.ca> In-Reply-To: X-Enigmail-Version: 1.2.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] New Version Notification for draft-bellis-behave-natpresent-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, 24 Oct 2011 13:57:25 -0000 On 2011-10-24 09:14, Ray Bellis wrote: > As it happens, the original idea came to me as a way of allowing > applications to "prefer" end-to-end clear paths over paths that go > through a CGN, i.e. an extra piece of information for "Happy > Eyeballs" algorithms. Got it. That makes sense. But we already have STUN for that, don't we? And STUN doesn't require cooperation from the NAT. Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From Ray.Bellis@nominet.org.uk Mon Oct 24 07:26: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 46A9921F8C92 for ; Mon, 24 Oct 2011 07:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.852 X-Spam-Level: X-Spam-Status: No, score=-7.852 tagged_above=-999 required=5 tests=[AWL=-1.253, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YijZuDZTDwCy for ; Mon, 24 Oct 2011 07:26:45 -0700 (PDT) Received: from mx1.knowthenet.org.uk (mx1.knowthenet.org.uk [213.248.199.2]) by ietfa.amsl.com (Postfix) with ESMTP id 520DF21F8C8E for ; Mon, 24 Oct 2011 07:26:45 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: Content-ID:Content-Transfer-Encoding:MIME-Version; b=2QvNyU2GKoW++m+argkJuwtX4VWdUyKd2objn0MDgSyUgNYBt/8lj5/Z 4jTRkJEPxXjemJW8iTNxSx8fklx1HznIQLYW9WF8RP7535XArOrfQY/pm K/ujTzdPaQ9tCEf; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1319466405; x=1351002405; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[BEHAVE]=20New=20Version=20Notification =20for=0D=0A=20draft-bellis-behave-natpresent-00.txt |Date:=20Mon,=2024=20Oct=202011=2014:26:43=20+0000 |Message-ID:=20<53C5645A-3729-4BED-B96D-D5C6DDD7BDBA@nomi net.org.uk>|To:=20Simon=20Perreault=20|CC:=20"behave@ietf.org"=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable|Content-ID:=20<8f1ee522-7005-402e-ba33-1bf7c3bc 02fd>|In-Reply-To:=20<4EA56EC4.8030101@viagenie.ca> |References:=20=0D=0A=20<4EA55995.6010808@viagenie.ca>=0D=0A =20 =0D=0A=20<4EA55EF7.4010603@viagenie.ca>=0D=0A=20=0D=0A=20<4EA 56EC4.8030101@viagenie.ca>; bh=3hrJb4NTL0CFU2Et0GLYCgweEZZA5xD0VzZkVBzu7sI=; b=Dn15IdRDomoW+mcxxQxBV+A9X2vSowbk0zUYyRU6UgL9mC4oamQpav5q ugIKzO7W3RB/I96VV6B9nx7zGwVMHwKzHKCTtGDjPBYhuYr6eaxaWMSF+ N1BCz/9CYgOnJ5s; X-IronPort-AV: E=Sophos;i="4.69,398,1315177200"; d="scan'208";a="36124400" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx3.nominet.org.uk with ESMTP; 24 Oct 2011 15:26:44 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%19]) with mapi; Mon, 24 Oct 2011 15:26:44 +0100 From: Ray Bellis To: Simon Perreault Thread-Topic: [BEHAVE] New Version Notification for draft-bellis-behave-natpresent-00.txt Thread-Index: AQHMkk7mxcZnQH58iESbRvpOk5XY6ZWLdFUAgAAIMYA= Date: Mon, 24 Oct 2011 14:26:43 +0000 Message-ID: <53C5645A-3729-4BED-B96D-D5C6DDD7BDBA@nominet.org.uk> References: <4EA55995.6010808@viagenie.ca> <4EA55EF7.4010603@viagenie.ca> <4EA56EC4.8030101@viagenie.ca> In-Reply-To: <4EA56EC4.8030101@viagenie.ca> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-ID: <8f1ee522-7005-402e-ba33-1bf7c3bc02fd> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] New Version Notification for draft-bellis-behave-natpresent-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, 24 Oct 2011 14:26:46 -0000 On 24 Oct 2011, at 14:57, Simon Perreault wrote: >=20 > Got it. That makes sense. But we already have STUN for that, don't we? > And STUN doesn't require cooperation from the NAT. >=20 The intention was for something lighter weight (and in-band). Ray From internet-drafts@ietf.org Mon Oct 24 08:20: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 DF63621F8E9E; Mon, 24 Oct 2011 08:20:44 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yuyt1UaE6RlT; Mon, 24 Oct 2011 08:20:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8253221F8E8D; Mon, 24 Oct 2011 08:20:38 -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.61 Message-ID: <20111024152038.17267.83781.idtracker@ietfa.amsl.com> Date: Mon, 24 Oct 2011 08:20:38 -0700 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action: draft-ietf-behave-lsn-requirements-04.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, 24 Oct 2011 15:20:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Behavior Engineering for Hindrance Av= oidance Working Group of the IETF. Title : Common requirements for Carrier Grade NAT (CGN) Author(s) : Simon Perreault Ikuhei Yamagata Shin Miyakawa Akira Nakagawa Hiroyuki Ashida Filename : draft-ietf-behave-lsn-requirements-04.txt Pages : 18 Date : 2011-10-24 This document defines common requirements for Carrier-Grade NAT (CGN). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-lsn-requirements-04.t= xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-lsn-requirements-04.txt From simon.perreault@viagenie.ca Mon Oct 24 08:24: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 8A6E321F8EA9 for ; Mon, 24 Oct 2011 08:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OvMMxSeGeSsF for ; Mon, 24 Oct 2011 08:24:38 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 5221421F8EA1 for ; Mon, 24 Oct 2011 08:24:38 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:21d:60ff:fed7:e732]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 61A3720D1D for ; Mon, 24 Oct 2011 11:24:37 -0400 (EDT) Message-ID: <4EA58333.3070405@viagenie.ca> Date: Mon, 24 Oct 2011 11:24:35 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110720 Thunderbird/5.0 MIME-Version: 1.0 To: behave@ietf.org References: <20111024152038.17267.83781.idtracker@ietfa.amsl.com> In-Reply-To: <20111024152038.17267.83781.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.2.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-lsn-requirements-04.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, 24 Oct 2011 15:24:40 -0000 On 2011-10-24 11:20, 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 : Common requirements for Carrier Grade NAT (CGN) > Author(s) : Simon Perreault > Ikuhei Yamagata > Shin Miyakawa > Akira Nakagawa > Hiroyuki Ashida > Filename : draft-ietf-behave-lsn-requirements-04.txt > Pages : 18 > Date : 2011-10-24 Change log: o Fixed nits, spelling, updated references. o CGNs SHOULD NOT log destinations. o Allow address-dependent filtering when it does not cause the application protocol to break. o Refer to RFC4787 security considerations on EIF. o Clarify REQ-12 point D (it does not apply to operator intervention). o Changed "CGNs SHOULD limit ..." to "SHOULD support limiting" to make it clear that the operator is in control. o Added reference to RFC 4963. o Added requirement for non-contiguous external address pools. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From huitema@microsoft.com Mon Oct 24 11:18: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 5AE4E11E80B5 for ; Mon, 24 Oct 2011 11:18:28 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xW2XrW30ulb9 for ; Mon, 24 Oct 2011 11:18:27 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id D3AAC11E80B4 for ; Mon, 24 Oct 2011 11:18:27 -0700 (PDT) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 24 Oct 2011 11:18:27 -0700 Received: from TK5EX14MBXC273.redmond.corp.microsoft.com ([169.254.1.51]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.01.0339.002; Mon, 24 Oct 2011 11:18:27 -0700 From: Christian Huitema To: Ray Bellis , Simon Perreault Thread-Topic: [BEHAVE] New Version Notification for draft-bellis-behave-natpresent-00.txt Thread-Index: AQHMklj/sifIbRx4p0CfP5Y3jMDb5ZWLzaZA Date: Mon, 24 Oct 2011 18:18:26 +0000 Message-ID: References: <4EA55995.6010808@viagenie.ca> <4EA55EF7.4010603@viagenie.ca> <4EA56EC4.8030101@viagenie.ca> <53C5645A-3729-4BED-B96D-D5C6DDD7BDBA@nominet.org.uk> In-Reply-To: <53C5645A-3729-4BED-B96D-D5C6DDD7BDBA@nominet.org.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.70] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] New Version Notification for draft-bellis-behave-natpresent-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, 24 Oct 2011 18:18:28 -0000 >> And STUN doesn't require cooperation from the NAT. >>=20 > > The intention was for something lighter weight (and in-band). Wouldn't it be nice to have a version of trace route that somehow returned = the list of NAT on the path, as well as the succession of translations? -- Christian Huitema From dwing@cisco.com Mon Oct 24 11:35: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 F08EC1F0C5B for ; Mon, 24 Oct 2011 11:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cNNbG7bqi+8W for ; Mon, 24 Oct 2011 11:35:40 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 602761F0C58 for ; Mon, 24 Oct 2011 11:35:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=727; q=dns/txt; s=iport; t=1319481340; x=1320690940; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=/O290ukP3LyzYNadMReDYY43lCqLVUDVUTUGj9G70ME=; b=RPS8NuiuRwMYE9RKFYdscg6CG104N3SQILDu9dEsBtrAfIte0RvNz53B QJSSW0DglyL6LNQVHNFEqPS52HVarYv4d7yWGrjtypWLhbanqke0Qeygp QlNokQEXEIgy3AY8LygR41096Tko5G1+y+qx+wctlW8G0hs63TbQsTk1L 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AroAAC+vpU6tJXHB/2dsb2JhbABDmVGBbI1VgQWBbgEBAQEDCAoBFxA9AgwBAwIJDwIEAQEoBxkjCgkIAgQBEgsXnTIBnh2IQASIBp1+ X-IronPort-AV: E=Sophos;i="4.69,399,1315180800"; d="scan'208";a="30621394" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 24 Oct 2011 18:35:40 +0000 Received: from dwingWS (rtp-vpn6-965.cisco.com [10.82.251.200]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p9OIZcZ4022812; Mon, 24 Oct 2011 18:35:39 GMT From: "Dan Wing" To: "'Christian Huitema'" , "'Ray Bellis'" , "'Simon Perreault'" References: <4EA55995.6010808@viagenie.ca> <4EA55EF7.4010603@viagenie.ca> <4EA56EC4.8030101@viagenie.ca> <53C5645A-3729-4BED-B96D-D5C6DDD7BDBA@nominet.org.uk> In-Reply-To: Date: Mon, 24 Oct 2011 11:35:38 -0700 Message-ID: <01be01cc927b$ba87dac0$2f979040$@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: AQHMklj/sifIbRx4p0CfP5Y3jMDb5ZWLzaZAgAAE6DA= Content-Language: en-us Cc: behave@ietf.org Subject: Re: [BEHAVE] New Version Notification for draft-bellis-behave-natpresent-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, 24 Oct 2011 18:35:42 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Christian Huitema > Sent: Monday, October 24, 2011 11:18 AM > To: Ray Bellis; Simon Perreault > Cc: behave@ietf.org > Subject: Re: [BEHAVE] New Version Notification for draft-bellis-behave- > natpresent-00.txt > > >> And STUN doesn't require cooperation from the NAT. > >> > > > > The intention was for something lighter weight (and in-band). > > Wouldn't it be nice to have a version of trace route that somehow > returned the list of NAT on the path, as well as the succession of > translations? Yes. I am planning to introduce that idea to PCP proxying soon after we wrap up pcp-base. -d From hannes.tschofenig@gmx.net Mon Oct 24 12:11: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 E386C21F8B88 for ; Mon, 24 Oct 2011 12:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.452 X-Spam-Level: X-Spam-Status: No, score=-102.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGQNPdmRgwq0 for ; Mon, 24 Oct 2011 12:11:56 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id BB32221F8B81 for ; Mon, 24 Oct 2011 12:11:54 -0700 (PDT) Received: (qmail invoked by alias); 24 Oct 2011 19:11:53 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [10.0.0.4]) [88.115.216.191] by mail.gmx.net (mp036) with SMTP; 24 Oct 2011 21:11:53 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+9fKUVbHG9iNKR51oUX/7rJrlet20C1ANIxpzNOH mMo+8y12s0xAP2 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <01be01cc927b$ba87dac0$2f979040$@com> Date: Mon, 24 Oct 2011 22:11:51 +0300 Content-Transfer-Encoding: 7bit Message-Id: <7CF71211-A506-402D-B734-D665AA085E1A@gmx.net> References: <4EA55995.6010808@viagenie.ca> <4EA55EF7.4010603@viagenie.ca> <4EA56EC4.8030101@viagenie.ca> <53C5645A-3729-4BED-B96D-D5C6DDD7BDBA@nominet.org.uk> <01be01cc927b$ba87dac0$2f979040$@com> To: "Dan Wing" X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: 'Ray Bellis' , behave@ietf.org Subject: Re: [BEHAVE] New Version Notification for draft-bellis-behave-natpresent-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, 24 Oct 2011 19:11:57 -0000 Funny enough we did all this in NSIS ;-) On Oct 24, 2011, at 9:35 PM, Dan Wing wrote: >> -----Original Message----- >> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On >> Behalf Of Christian Huitema >> Sent: Monday, October 24, 2011 11:18 AM >> To: Ray Bellis; Simon Perreault >> Cc: behave@ietf.org >> Subject: Re: [BEHAVE] New Version Notification for draft-bellis-behave- >> natpresent-00.txt >> >>>> And STUN doesn't require cooperation from the NAT. >>>> >>> >>> The intention was for something lighter weight (and in-band). >> >> Wouldn't it be nice to have a version of trace route that somehow >> returned the list of NAT on the path, as well as the succession of >> translations? > > Yes. I am planning to introduce that idea to PCP proxying soon after > we wrap up pcp-base. > > -d > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From huitema@microsoft.com Mon Oct 24 12:17: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 460DF21F8BB7 for ; Mon, 24 Oct 2011 12:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XEijsmAC5+yv for ; Mon, 24 Oct 2011 12:17:22 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id B5D4E21F8BB5 for ; Mon, 24 Oct 2011 12:17:22 -0700 (PDT) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 24 Oct 2011 12:17:22 -0700 Received: from TK5EX14MBXC273.redmond.corp.microsoft.com ([169.254.1.51]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.01.0339.002; Mon, 24 Oct 2011 12:17:22 -0700 From: Christian Huitema To: Hannes Tschofenig , Dan Wing Thread-Topic: [BEHAVE] New Version Notification for draft-bellis-behave-natpresent-00.txt Thread-Index: AQHMklj/sifIbRx4p0CfP5Y3jMDb5ZWLzaZAgAAE6DCAAH+qgP//i6/w Date: Mon, 24 Oct 2011 19:17:21 +0000 Message-ID: References: <4EA55995.6010808@viagenie.ca> <4EA55EF7.4010603@viagenie.ca> <4EA56EC4.8030101@viagenie.ca> <53C5645A-3729-4BED-B96D-D5C6DDD7BDBA@nominet.org.uk> <01be01cc927b$ba87dac0$2f979040$@com> <7CF71211-A506-402D-B734-D665AA085E1A@gmx.net> In-Reply-To: <7CF71211-A506-402D-B734-D665AA085E1A@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.70] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'Ray Bellis' , "behave@ietf.org" Subject: Re: [BEHAVE] New Version Notification for draft-bellis-behave-natpresent-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, 24 Oct 2011 19:17:23 -0000 I am aware of NSIS. But the premise of NSIS is that software gets implement= ed in the translators, and that has proven quite hard. A "trace route" appr= oach would work even if a minority of the routers on the path supported it. -----Original Message----- From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]=20 Sent: Monday, October 24, 2011 12:12 PM To: Dan Wing Cc: Hannes Tschofenig; Christian Huitema; 'Ray Bellis'; 'Simon Perreault'; = behave@ietf.org Subject: Re: [BEHAVE] New Version Notification for draft-bellis-behave-natp= resent-00.txt Funny enough we did all this in NSIS ;-) On Oct 24, 2011, at 9:35 PM, Dan Wing wrote: >> -----Original Message----- >> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On=20 >> Behalf Of Christian Huitema >> Sent: Monday, October 24, 2011 11:18 AM >> To: Ray Bellis; Simon Perreault >> Cc: behave@ietf.org >> Subject: Re: [BEHAVE] New Version Notification for=20 >> draft-bellis-behave- natpresent-00.txt >>=20 >>>> And STUN doesn't require cooperation from the NAT. >>>>=20 >>>=20 >>> The intention was for something lighter weight (and in-band). >>=20 >> Wouldn't it be nice to have a version of trace route that somehow=20 >> returned the list of NAT on the path, as well as the succession of=20 >> translations? >=20 > Yes. I am planning to introduce that idea to PCP proxying soon after=20 > we wrap up pcp-base. >=20 > -d >=20 >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From Ray.Bellis@nominet.org.uk Sun Oct 23 05:44: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 5CD6D21F8586 for ; Sun, 23 Oct 2011 05:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.694 X-Spam-Level: X-Spam-Status: No, score=-9.694 tagged_above=-999 required=5 tests=[AWL=0.905, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qzf-Qtl-4LLQ for ; Sun, 23 Oct 2011 05:44:13 -0700 (PDT) Received: from mx4.nominet.org.uk (mail.nominet.org.uk [213.248.199.24]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2F021F8564 for ; Sun, 23 Oct 2011 05:44:10 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: Content-Transfer-Encoding:MIME-Version; b=tml6f2YtD6CFMZxtPSUvjTRBy1D9yTpDg0i5/Jgai9k6NVx+h0EMQAUe YQcqc62eMO4pqgcSmg/788AKTqphfrVr9DmNpmMG5qFD/mKozkoIvjvOy 7KbUZKgVOP2D6o5; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1319373851; x=1350909851; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20FW:=20New=20Version=20Notification=20for=0D =0A=20draft-bellis-behave-natpresent-00.txt|Date:=20Sun, =2023=20Oct=202011=2012:41:39=20+0000|Message-ID:=20<8B7F 972437853B40865000D86857B1D118DA2719@wds-exc1.okna.nomine t.org.uk>|To:=20"behave@ietf.org"=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable|In-Reply-To:=20<20111023095926.15787.63699.idtr acker@ietfa.amsl.com>|References:=20<20111023095926.15787 .63699.idtracker@ietfa.amsl.com>; bh=OkOhTOuwoCzD5ePhPnQ8oFcbYkrDXG9EG9Lusx1oDh4=; b=GMwAfydtcxHVSMhAPXzLjtEalvpZ9SYYL6dHz0YtzXgd/7xXen+HPqDf 7JjEP3MUcY3Goz2EOPeiWprJbW9/ClCmDToSP9CbWNZ6X62Wlb7/XjPTI xH/1TCoOvtipN72; X-IronPort-AV: E=Sophos;i="4.69,393,1315177200"; d="scan'208";a="29137551" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx4.nominet.org.uk with ESMTP; 23 Oct 2011 13:44:08 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%19]) with mapi; Sun, 23 Oct 2011 13:44:08 +0100 From: Ray Bellis To: "behave@ietf.org" Thread-Topic: New Version Notification for draft-bellis-behave-natpresent-00.txt Thread-Index: AQHMkWp09eF0fKXKiEuf19T0eYY13JWJ32Pu Date: Sun, 23 Oct 2011 12:41:39 +0000 Message-ID: <8B7F972437853B40865000D86857B1D118DA2719@wds-exc1.okna.nominet.org.uk> References: <20111023095926.15787.63699.idtracker@ietfa.amsl.com> In-Reply-To: <20111023095926.15787.63699.idtracker@ietfa.amsl.com> Accept-Language: en-GB, 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-Mailman-Approved-At: Tue, 25 Oct 2011 09:06:16 -0700 Subject: [BEHAVE] FW: New Version Notification for draft-bellis-behave-natpresent-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2011 12:44:14 -0000 Forwarded for the group's information:=0A= =0A= The primary intent is for Layer 7 applications to be able to receive explic= it in-band notification of modifications at L3/L4.=0A= =0A= Ray=0A= =0A= --8<--8<--=0A= Subject: New Version Notification for draft-bellis-behave-natpresent-00.txt= =0A= =0A= A new version of I-D, draft-bellis-behave-natpresent-00.txt has been succes= sfully submitted by Ray Bellis and posted to the IETF repository.=0A= =0A= Filename: draft-bellis-behave-natpresent=0A= Revision: 00=0A= Title: Signalling the Presence of NAT=0A= Creation date: 2011-10-23=0A= WG ID: Individual Submission=0A= Number of pages: 7=0A= =0A= Abstract:=0A= End-to-end applications have difficulty distinguishing between=0A= packets that have been passed through a Network Address Translator=0A= (NAT) and packets that have been passed along a clear end-to-end=0A= path. We propose mechanisms for IPv4 and IPv6 whereby NAT devices=0A= explicitly signal their operation as a means of allowing applications=0A= to distinguish the presence of otherwise undetected NATs in the end-=0A= to-end path.=0A= =0A= --8<--8<--=0A= From Ray.Bellis@nominet.org.uk Tue Oct 25 09:10: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 4514021F8C60 for ; Tue, 25 Oct 2011 09:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.101 X-Spam-Level: X-Spam-Status: No, score=-7.101 tagged_above=-999 required=5 tests=[AWL=-1.794, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rkXBYv6ci6mF for ; Tue, 25 Oct 2011 09:10:39 -0700 (PDT) Received: from mx1.knowthenet.org.uk (mx1.knowthenet.org.uk [213.248.199.2]) by ietfa.amsl.com (Postfix) with ESMTP id 8B19B21F8C45 for ; Tue, 25 Oct 2011 09:10:38 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: Content-ID:Content-Transfer-Encoding:MIME-Version; b=cycCMEB6stjysbkiXqHNwaamaXstkWMSJM1/kw4BKjIaiFXgf35lvnaw 82hoNglzDglP8L7kzVfoOu5G/zYTzLWaI7Nu/bXzufkmPJ+vaCRwRNCuy hU49HU6hizElFo3; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1319559038; x=1351095038; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[BEHAVE]=20New=20Version=20Notification =20for=0D=0A=20draft-bellis-behave-natpresent-00.txt |Date:=20Tue,=2025=20Oct=202011=2016:10:35=20+0000 |Message-ID:=20<44518C65-49B7-4BD6-97D7-A9E153EBDCE5@nomi net.org.uk>|CC:=20"behave@ietf.org"=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable|Content-ID:=20<78c9263d-8353-48b2-a2ca-c5d99864 4922>|In-Reply-To:=20<8B7F972437853B40865000D86857B1D118D A2719@wds-exc1.okna.nominet.org.uk>|References:=20<201110 23095926.15787.63699.idtracker@ietfa.amsl.com>=0D=0A=20<8 B7F972437853B40865000D86857B1D118DA2719@wds-exc1.okna.nom inet.org.uk>; bh=Pbnr9A7CCV7pVGucuFhexuujOYQu7Js7UMILARlBsx0=; b=o3nQhKeVvy7aBX1Fc4STl2WZWZ8c5oHyJDi69gKjJiv7qbBDUx64vMML 8psyxSxJN2X4W8ZqyfaW2BcW4c+lL5bOrKhOvijSmSWqjaGce2Jmcp2WS vxUrsfca/WEDdBL; X-IronPort-AV: E=Sophos;i="4.69,404,1315177200"; d="scan'208";a="36151623" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx3.nominet.org.uk with ESMTP; 25 Oct 2011 17:10:36 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%19]) with mapi; Tue, 25 Oct 2011 17:10:36 +0100 From: Ray Bellis CC: "behave@ietf.org" Thread-Topic: [BEHAVE] New Version Notification for draft-bellis-behave-natpresent-00.txt Thread-Index: AQHMkzChB4zJDmlSy0KOllAU3etSpA== Date: Tue, 25 Oct 2011 16:10:35 +0000 Message-ID: <44518C65-49B7-4BD6-97D7-A9E153EBDCE5@nominet.org.uk> References: <20111023095926.15787.63699.idtracker@ietfa.amsl.com> <8B7F972437853B40865000D86857B1D118DA2719@wds-exc1.okna.nominet.org.uk> In-Reply-To: <8B7F972437853B40865000D86857B1D118DA2719@wds-exc1.okna.nominet.org.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <78c9263d-8353-48b2-a2ca-c5d998644922> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] New Version Notification for draft-bellis-behave-natpresent-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, 25 Oct 2011 16:10:40 -0000 On 23 Oct 2011, at 13:41, Ray Bellis wrote: > Forwarded for the group's information: Ah, I wondered what happened to this - it was stuck in the moderator's queu= e because I hadn't 100% completed my Mailman subscription process. Ray From ssenthil@cisco.com Tue Oct 25 14:14:38 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7965D1F0C55 for ; Tue, 25 Oct 2011 14:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.135 X-Spam-Level: X-Spam-Status: No, score=-3.135 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NM2y3xWJBOrW for ; Tue, 25 Oct 2011 14:14:37 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id E42E31F0C43 for ; Tue, 25 Oct 2011 14:14:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ssenthil@cisco.com; l=5212; q=dns/txt; s=iport; t=1319577277; x=1320786877; h=date:subject:from:to:cc:message-id:mime-version; bh=9FzHj1+fzQJpPy4oQKcDFxLF7XMZ+h2TwICmYxGgwp0=; b=huyNXgTmteoMVRXprhItVG5IfxNBqR2fsc+snoDvY41M1v27VsSEM9vg D8k42H6tqcb36rkasot/tziDesl80oSsnSKS1nUA4qgSsAE3N4u7KmbzH a7y5b5FAXPT3dYZWzcig9KjoU5ga/CQ7YYc5bKTWTCETZPGx5bflPRM+I s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am4FAKglp06rRDoJ/2dsb2JhbABCgk2GcJ1dgRB3AoEFgXABBBIBKjwSAQwFgRUBBA4nnVEBnmaIVgSHVoUhhxOFNYxF X-IronPort-AV: E=Sophos;i="4.69,405,1315180800"; d="scan'208,217";a="10238884" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 25 Oct 2011 21:14:36 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9PLEZ3E023172; Tue, 25 Oct 2011 21:14:35 GMT Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 25 Oct 2011 14:14:35 -0700 Received: from 64.102.206.102 ([64.102.206.102]) by xmb-sjc-236.amer.cisco.com ([128.107.191.121]) with Microsoft Exchange Server HTTP-DAV ; Tue, 25 Oct 2011 21:14:35 +0000 User-Agent: Microsoft-Entourage/12.31.0.110725 Date: Tue, 25 Oct 2011 17:14:33 -0400 From: ssenthil To: Message-ID: Thread-Topic: Comments on draft-xli-behave-divi-03 Thread-Index: AcyTWxdaWXm4gh5keE6dEr03FETi0g== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3402407674_24630193" X-OriginalArrivalTime: 25 Oct 2011 21:14:35.0750 (UTC) FILETIME=[18FDE060:01CC935B] Cc: congxiao@cernet.edu.cn, xing@cernet.edu.cn Subject: [BEHAVE] Comments on draft-xli-behave-divi-03 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, 25 Oct 2011 21:14:38 -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_3402407674_24630193 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Section 4 : Port set algorithm. #1 There is not much information on how the CPEs are provisioned with the port ranges and the how the CPEs know their value of K. Some details are required to make that clear. #2 =B3For given multiplexing ratio N, the port-set numbers of a IPv4- translatable address with port-set-id K is composed of P=3Dj*N + K + 1024, for all the values of j=3D0, 1, ..., (65536-N)/N. .... For example, If N=3D128, then IPv6 node K=3D5 is only allowed to use port numbers 5, 133, 261, 389, 517, 645, 773, 901, ... 65,413 as the source port, while the packets with these port numbers as the destination port number will be send to IPv6 node K=3D5.=B2 As per the above algorithm the ports could never be < 1024. Also, Table 5.2 shows that the # of ports without excluding the low range of ports. You should fix that as well. #3 Section 5.1 Extended address format Third paragraph: It says =B34 bits is enough for N=B2, but there is no explanation as to why until the reader gets to Section 5.2 to understand what you=B9re saying. I would suggest adding some text here in this section and/or reference to Figure 5. #4 Appendix A. The prefix selected is 2001:da8:a4a6::/48 but the examples use 2001:da8:b4b6:: addresses Editorial #1 Section 4. For example, If N=3D128, then IPv6 node K=3D5 is only allowed to use port numbers 5, 133, 261, 389, 517, 645, 773, 901, ... 65,413 as the source port, while the packets with these port numbers as the destination port number will be send(sent) to IPv6 node K=3D5. #2 In the same section: 2. The individual ports for each IPv6 node are not continues (continuous) and the whole 65536 port range is equally shared by IPv6 nodes. --B_3402407674_24630193 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Comments on draft-xli-behave-divi-03 Section 4 : Port set algorithm.
#1
There is not much information on how the CPEs are provisioned with the port= ranges and the how the CPEs know their value of K.
Some details are required to make that clear.

#2
“For given multiplexing ratio N, the port-set numbers= of a IPv4-
      translatable address with port-set-id K= is composed of P=3Dj*N + K +
      1024, for all the values of j=3D0, 1, ...= , (65536-N)/N.
....

   For example, If N=3D128, then IPv6 node K=3D5 is only allowed= to use port
   numbers 5, 133, 261, 389, 517, 645, 773, 901, ... 65,413 = as the
   source port, while the packets with these port numbers as= the
   destination port number will be send to IPv6 node K=3D5.= 221;

As per the above algorithm the ports could never be &= lt; 1024. Also, Table 5.2 shows that the # of ports without excluding the lo= w range of ports.
You should fix that as well.

#3
Section 5.1 Extended address format

Third paragraph: It says “4 bits is enough for N”, but there is= no explanation as to why until the reader gets to Section 5.2 to understand= what you’re saying. I would suggest adding some text here in this sec= tion and/or reference to Figure 5.  

#4
Appendix A.
The prefix selected is 2001:da8:a4a6::/48 but the examples use 2001:da8:b4b= 6:: addresses


Editorial
#1
Section 4.
For example, If N=3D128, then IPv6 node K=3D5 is only allowed t= o use port
   numbers 5, 133, 261, 389, 517, 645, 773, 901, ... 65,413 = as the
   source port, while the packets with these port numbers as= the
   destination port number will be sen= d(sent) to IPv6 node K=3D5.

#2
In the same section:
2.  The individual ports for each IPv6 node are not continues (continuous) and the
       whole 65536 port range is equally= shared by IPv6 nodes. --B_3402407674_24630193-- From dwing@cisco.com Tue Oct 25 17:06:36 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 972A011E8090 for ; Tue, 25 Oct 2011 17:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.467 X-Spam-Level: X-Spam-Status: No, score=-105.467 tagged_above=-999 required=5 tests=[AWL=1.132, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYnoHoB5tFjz for ; Tue, 25 Oct 2011 17:06:36 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 0C74111E808C for ; Tue, 25 Oct 2011 17:06:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=454; q=dns/txt; s=iport; t=1319587596; x=1320797196; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=JMxcbwmy+Dotl/I0KXR3vQgwVuZwyZXdURWUu6Sd0ME=; b=YDJgQzhSNhutiqecEPpLgrV07U+sc+ovPBiciSjNaKsRBXVu0fpRO/k2 POMyVnz5z0c6OlCU91+77X/EXoKXxOaNpKn/2GShMR+/cXHlx4Lf07WPv 3Nqw95rBybgeMjGFtDme/UHOVNoBLvUn/kE4pKacmQlEYp5IwNLKraEDA U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AroHAAlOp06rRDoH/2dsb2JhbABCmiOBKY1XgQWBdQgKARcQLQcLDQUYUCMcAQQTCxeHZpYSAZ5aiFYEiAaeAg X-IronPort-AV: E=Sophos;i="4.69,406,1315180800"; d="scan'208";a="10251391" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 26 Oct 2011 00:06:36 +0000 Received: from dwingWS ([10.21.75.193]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9Q06ZRv025075; Wed, 26 Oct 2011 00:06:35 GMT From: "Dan Wing" To: Date: Tue, 25 Oct 2011 17:06:35 -0700 Message-ID: <073701cc9373$20329610$6097c230$@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: AcyTcx/euGpfjgmKTsW7Gv+plECawg== Content-Language: en-us Cc: behave-chairs@tools.ietf.org, draft-ietf-behave-lsn-requirements@tools.ietf.org Subject: [BEHAVE] WGLC for draft-ietf-behave-lsn-requirements-04, Common requirements for Carrier Grade NAT (CGN) 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, 26 Oct 2011 00:06:36 -0000 We are starting a two-week WGLC for draft-ietf-behave-lsn-requirements-04, ending November 8. Please send substantive comments to the mailing list at behave@ietf.org, and, if possible, send editing nits directly to the authors at draft-ietf-behave-lsn-requirements@tools.ietf.org. http://tools.ietf.org/html/draft-ietf-behave-lsn-requirements-04 Abstract: This document defines common requirements for Carrier-Grade NAT (CGN). -d From xing@cernet.edu.cn Wed Oct 26 06:25: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 32BA521F8AB8 for ; Wed, 26 Oct 2011 06:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.311 X-Spam-Level: X-Spam-Status: No, score=-99.311 tagged_above=-999 required=5 tests=[AWL=-0.292, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYwWZbb0VoB4 for ; Wed, 26 Oct 2011 06:25:52 -0700 (PDT) Received: from cernet.edu.cn (mail.cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with SMTP id B034521F8A58 for ; Wed, 26 Oct 2011 06:25:51 -0700 (PDT) Received: from [127.0.0.1]([125.34.40.27]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm144ea819d8; Wed, 26 Oct 2011 21:25:49 +0800 Message-ID: <4EA80A4D.20705@cernet.edu.cn> Date: Wed, 26 Oct 2011 21:25:33 +0800 From: Xing Li User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; zh-CN; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15 MIME-Version: 1.0 To: ssenthil References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------050405060804060707040509" X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: vlV4DT1B Cc: Xing Li , congxiao@cernet.edu.cn, behave@ietf.org Subject: Re: [BEHAVE] Comments on draft-xli-behave-divi-03 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, 26 Oct 2011 13:25:54 -0000 This is a multi-part message in MIME format. --------------050405060804060707040509 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Thanks for the comments. ? 2011/10/26 5:14, ssenthil ??: > Section 4 : Port set algorithm. > #1 > There is not much information on how the CPEs are provisioned with the > port ranges and the how the CPEs know their value of K. > Some details are required to make that clear. The DHCPv6 option extension will be used for the provisioning of the CPE, the current information required are the IPv6 prefix, the sharing ratio and the PSID (k). We will add more details in the next upload. > > #2 > "For given multiplexing ratio N, the port-set numbers of a IPv4- > translatable address with port-set-id K is composed of P=j*N + K + > 1024, for all the values of j=0, 1, ..., (65536-N)/N. > .... > > For example, If N=128, then IPv6 node K=5 is only allowed to use port > numbers 5, 133, 261, 389, 517, 645, 773, 901, ... 65,413 as the > source port, while the packets with these port numbers as the > destination port number will be send to IPv6 node K=5." > > As per the above algorithm the ports could never be < 1024. Also, > Table 5.2 shows that the # of ports without excluding the low range of > ports. > You should fix that as well. Thanks. We will correct the numbers. > > #3 > Section 5.1 Extended address format > > Third paragraph: It says "4 bits is enough for N", but there is no > explanation as to why until the reader gets to Section 5.2 to > understand what you're saying. I would suggest adding some text here > in this section and/or reference to Figure 5. > Thanks. > #4 > Appendix A. > The prefix selected is 2001:da8:a4a6::/48 but the examples use > 2001:da8:b4b6:: addresses > Thanks. > > Editorial > #1 > Section 4. > For example, If N=128, then IPv6 node K=5 is only allowed to use port > numbers 5, 133, 261, 389, 517, 645, 773, 901, ... 65,413 as the > source port, while the packets with these port numbers as the > destination port number will be send(sent) to IPv6 node K=5. > > #2 > In the same section: > 2. The individual ports for each IPv6 node are not continues > (continuous) and the > whole 65536 port range is equally shared by IPv6 nodes. Thanks. We will upload a new version soon and the progress of the dIVI-PD unification in softwire working group will also be added. Regards, xing > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave --------------050405060804060707040509 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

Thanks for the comments.

于 2011/10/26 5:14, ssenthil 写道:
Comments on draft-xli-behave-divi-03 Section 4 : Port set algorithm.
#1
There is not much information on how the CPEs are provisioned with the port ranges and the how the CPEs know their value of K.
Some details are required to make that clear.

The DHCPv6 option extension will be used for the provisioning of the CPE, the current information required are the IPv6 prefix, the sharing ratio and the PSID (k). We will add more details in the next upload.


#2
“For given multiplexing ratio N, the port-set numbers of a IPv4-
      translatable address with port-set-id K is composed of P=j*N + K +
      1024, for all the values of j=0, 1, ..., (65536-N)/N.
....

   For example, If N=128, then IPv6 node K=5 is only allowed to use port
   numbers 5, 133, 261, 389, 517, 645, 773, 901, ... 65,413 as the
   source port, while the packets with these port numbers as the
   destination port number will be send to IPv6 node K=5.”

As per the above algorithm the ports could never be < 1024. Also, Table 5.2 shows that the # of ports without excluding the low range of ports.
You should fix that as well.

Thanks. We will correct the numbers.


#3
Section 5.1 Extended address format

Third paragraph: It says “4 bits is enough for N”, but there is no explanation as to why until the reader gets to Section 5.2 to understand what you’re saying. I would suggest adding some text here in this section and/or reference to Figure 5.  


Thanks.

#4
Appendix A.
The prefix selected is 2001:da8:a4a6::/48 but the examples use 2001:da8:b4b6:: addresses


Thanks.


Editorial
#1
Section 4.
For example, If N=128, then IPv6 node K=5 is only allowed to use port
   numbers 5, 133, 261, 389, 517, 645, 773, 901, ... 65,413 as the
   source port, while the packets with these port numbers as the
   destination port number will be send(sent) to IPv6 node K=5.

#2
In the same section:
2.  The individual ports for each IPv6 node are not continues (continuous) and the
       whole 65536 port range is equally shared by IPv6 nodes. 

    

    

    Thanks.

    

    We will upload a new version soon and the progress of the dIVI-PD
    unification in softwire working group will also be added.

    

    Regards,

    

    xing

    

    

    

      

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


    

    

  


--------------050405060804060707040509--

From ovautrin@juniper.net  Fri Oct 28 17:55: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 8541411E8088 for ; Fri, 28 Oct 2011 17:55:17 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hskvnHrCXHvS for ; Fri, 28 Oct 2011 17:55:16 -0700 (PDT)
Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC5E11E8081 for ; Fri, 28 Oct 2011 17:55:16 -0700 (PDT)
Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP;  Fri, 28 Oct 2011 17:55:16 PDT
Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Fri, 28 Oct 2011 17:44:28 -0700
From: Olivier Vautrin 
To: Benson Schliesser , Dan Wing 
Date: Fri, 28 Oct 2011 17:44:27 -0700
Thread-Topic: [BEHAVE] CGN Requirements: logging (draft-ietf-behave-lsn-requirements)
Thread-Index: AcyV0+ng+C+PDM60SaKo+yHYBtaiEg==
Message-ID: 
In-Reply-To: <5A453A14-04D0-4DA5-A7AC-970D7579F4DE@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.13.0.110805
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "behave@ietf.org" 
Subject: Re: [BEHAVE] CGN Requirements: logging (draft-ietf-behave-lsn-requirements)
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, 29 Oct 2011 00:55:17 -0000

What about the "bulk port allocation"? The draft is explaining in detail
the mechanism but do not give any recommendation. I think we should at
least have a "SHOULD" to support the bulk port allocation. It is difficult
to believe that in the future, service providers we will still log all the
sessions on a CGN device.

/Olivier

On 10/18/11 11:23 AM, "Benson Schliesser"  wrote:

>
>On Oct 17, 2011, at 3:49 PM, Dan Wing wrote:
>
>>>> To align draft-ietf-behave-lsn-requirements with RFC6302 ("Logging
>>>> Recommendations for Internet-Facing Servers"), should
>>>> draft-ietf-behave-lsn-requirements instead state that destination
>>>> logging SHOULD NOT be performed, and recommend that a CGN simply
>>>> do source port logging in anticipation of servers following
>>>> RFC6302?
>>>=20
>>> I don't think draft-ietf-behave-lsn-requirements should specify one way
>>> or the other.  I do think that it should discuss the topic in "MAY"
>>> terms, and give appropriate cautions.
>>>=20
>>> Clearly, logging destination along with translated and original source
>>> address + port would reveal customer behavior in some detail.  Logging
>>> only the translated and original address + port would be adequate for
>>> law enforcement requests targeting specific historical transactions.
>>=20
>> It seems that is the core of the requirement created by IPv4 address
>> sharing, especially in light of RFC6302 (Logging Recommendations for
>> Internet-Facing Servers).
>
>Yes, and I agree that logging translated and original source address +
>port is something that might be a SHOULD or MUST requirement.
>
>>> Logging only destination (and nothing else, or decoupled from source
>>> logging) might be informative from a demographic perspective, but has a
>>> smaller privacy impact.
>>>=20
>>> While I personally don't find the privacy implications very appealing,
>>> I know that this kind of intelligence is already gathered by some ISPs.
>>> (With DPI tools etc.)  There may be law enforcement and/or business
>>> reasons that they want this, and making the IETF document take an
>>> opposition position would only cause problems - vendors will still
>>> produce what SP customers want, resulting in a situation where CGN
>>> products are frequently not compliant with this document.
>>=20
>> Considering such a requirement exists in some places (today) without
>> CGN, the deployment of a CGN would not affect those network's
>>requirements
>> to do destination logging -- they would still be required to log
>> destination.  I don't want to conflate "logging destinations is needed
>> in Country X" with "CGN requires logging destinations".
>
>I agree, we should not conflate these topics. That's why the requirements
>document should avoid "SHOULD NOT" or "MUST NOT" language, with regard to
>destination logging.
>
>Cheers,
>-Benson
>
>_______________________________________________
>Behave mailing list
>Behave@ietf.org
>https://www.ietf.org/mailman/listinfo/behave


From bschlies@cisco.com  Fri Oct 28 20:21:52 2011
Return-Path: 
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 411021F0C4A for ; Fri, 28 Oct 2011 20:21:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.199
X-Spam-Level: 
X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=0.400,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDM8XpdmOQHo for ; Fri, 28 Oct 2011 20:21:51 -0700 (PDT)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2BE11E8081 for ; Fri, 28 Oct 2011 20:21:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=1003; q=dns/txt; s=iport; t=1319858505; x=1321068105; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=oJRdhhxom3XI4kYgZ3Tq5YBMxc64YlJZgZKgDNl76io=; b=V1RB/DMqQI+IQ8hSSFgjoI0ykRo3nU+Q5jjfuZ/xeSeadJ/HQQQak3XH Ru4WjJWzjMmMjftw7ieLf07lyZLoaqtZr/OlckQSu3w6s72gFD5zMSI2l +fBuI82PtkkSRTx3rNqb+OJSLzaQXJl4ZGATHS+sYgTHYG356FEY2bicE 8=;
X-IronPort-AV: E=Sophos;i="4.69,422,1315180800"; d="scan'208";a="11066746"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 29 Oct 2011 03:21:45 +0000
Received: from [192.168.0.133] (sjc-vpn7-236.cisco.com [10.21.144.236]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9T3LiFP018636; Sat, 29 Oct 2011 03:21:44 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Benson Schliesser 
In-Reply-To: 
Date: Fri, 28 Oct 2011 22:21:44 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <412F66EB-9ADF-448D-9324-582F2D0B9AFD@cisco.com>
References: 
To: Olivier Vautrin 
X-Mailer: Apple Mail (2.1084)
Cc: "behave@ietf.org" , Dan Wing 
Subject: Re: [BEHAVE] CGN Requirements: logging (draft-ietf-behave-lsn-requirements)
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, 29 Oct 2011 03:21:52 -0000

On Oct 28, 2011, at 7:44 PM, Olivier Vautrin wrote:

> What about the "bulk port allocation"? The draft is explaining in =
detail
> the mechanism but do not give any recommendation. I think we should at
> least have a "SHOULD" to support the bulk port allocation. It is =
difficult
> to believe that in the future, service providers we will still log all =
the
> sessions on a CGN device.

I tend to agree with your conclusion.  However, if we do per-connection =
allocation of ports, then there might be benefits to the CGN operator =
and users.  For instance, there might be improved security and more =
efficient utilization of CGN port resources.  Thus, an operator that =
doesn't care about logging might not want to use bulk port allocation.

My opinion is that if we say that a CGN "SHOULD" do bulk port =
allocation, then we should also say that it "MAY" do per-connection port =
allocation (based on the rationale I just described).  Thoughts on this?

Cheers,
-Benson


From cb.list6@gmail.com  Fri Oct 28 22:20: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 3C73D21F861E for ; Fri, 28 Oct 2011 22:20:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.767
X-Spam-Level: 
X-Spam-Status: No, score=-2.767 tagged_above=-999 required=5 tests=[AWL=0.832,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1oLdBcUF3ev for ; Fri, 28 Oct 2011 22:20:45 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id B0B7921F8610 for ; Fri, 28 Oct 2011 22:20:45 -0700 (PDT)
Received: by iabn5 with SMTP id n5so6059021iab.31 for ; Fri, 28 Oct 2011 22:20:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=LyPrpRGXUrZHvDZ6VaV7wlIs6Bwy6DBu88ycYuSDisc=; b=AEKGDsFkppBlzLHw1oXZ2CNkprqcuyl8UDt5+G58E3xoFSsNIEZYccj4DXOhvak0xA bItVGjPUcPSeYsQ0tL68EkbDArdZjikzhYMs7TRFmsVGhygyQ16j4Ous4cK03Eby1LzS KEBwJjfFpG3+kgwQYSxWtWhrvb3Rq/4/2Y8U0=
MIME-Version: 1.0
Received: by 10.68.12.104 with SMTP id x8mr8113087pbb.79.1319865644077; Fri, 28 Oct 2011 22:20:44 -0700 (PDT)
Received: by 10.142.230.8 with HTTP; Fri, 28 Oct 2011 22:20:43 -0700 (PDT)
In-Reply-To: <412F66EB-9ADF-448D-9324-582F2D0B9AFD@cisco.com>
References:  <412F66EB-9ADF-448D-9324-582F2D0B9AFD@cisco.com>
Date: Fri, 28 Oct 2011 22:20:43 -0700
Message-ID: 
From: Cameron Byrne 
To: Benson Schliesser 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "behave@ietf.org" , Olivier Vautrin , Dan Wing 
Subject: Re: [BEHAVE] CGN Requirements: logging (draft-ietf-behave-lsn-requirements)
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, 29 Oct 2011 05:20:46 -0000

On Fri, Oct 28, 2011 at 8:21 PM, Benson Schliesser  wro=
te:
>
> On Oct 28, 2011, at 7:44 PM, Olivier Vautrin wrote:
>
>> What about the "bulk port allocation"? The draft is explaining in detail
>> the mechanism but do not give any recommendation. I think we should at
>> least have a "SHOULD" to support the bulk port allocation. It is difficu=
lt
>> to believe that in the future, service providers we will still log all t=
he
>> sessions on a CGN device.
>
> I tend to agree with your conclusion. =A0However, if we do per-connection=
 allocation of ports, then there might be benefits to the CGN operator and =
users. =A0For instance, there might be improved security and more efficient=
 utilization of CGN port resources. =A0Thus, an operator that doesn't care =
about logging might not want to use bulk port allocation.
>
> My opinion is that if we say that a CGN "SHOULD" do bulk port allocation,=
 then we should also say that it "MAY" do per-connection port allocation (b=
ased on the rationale I just described). =A0Thoughts on this?
>

I would rather not see any recommendation here.  SHOULD is in fact a
very strong word in the IETF.  If something must be said, then we
should say both SHOULD be implemented for the operator to choose.

I have been operating a CGN probably longer than there has been the
term CGN without bulk port and i see no compelling reason to change.
In fact, we had an operational issue with a new CGN implementation
that was reserving ports and had a substantial issue load-balancing
bulk connections over CPU cores when bittorrent clients would request
thousands of connections from a single internal IP... resulting in bad
chunking effects.

Cameron


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

From iljitsch@muada.com  Sat Oct 29 01:15:34 2011
Return-Path: 
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0470621F86A0 for ; Sat, 29 Oct 2011 01:15:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.772
X-Spam-Level: *
X-Spam-Status: No, score=1.772 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, GB_ROLEX=5,  HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, MIME_QP_LONG_LINE=1.396, RCVD_IN_NJABL_PROXY=1.643, RCVD_IN_PBL=0.905,  RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_SPEC_ROLEX=1.666, SARE_UNI=0.591, SARE_URI_ANUMA=0.632, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJ8wq6VaBxZw for ; Sat, 29 Oct 2011 01:15:33 -0700 (PDT)
Received: from akolaserver (unknown [59.95.72.33]) by ietfa.amsl.com (Postfix) with SMTP id DE40421F8906 for ; Sat, 29 Oct 2011 01:15:31 -0700 (PDT)
Content-Return: allowed
X-Mailer: CME-V6.5.4.3; MSN
Message-ID: <20111029120544.2841.qmail@59.95.72.33>
From: ROLEX.COM 
To: 
MIME-Version: 1.0
Content-type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Date: Sat, 29 Oct 2011 01:15:31 -0700 (PDT)
Subject: [BEHAVE] behave@ietf.org Rolex -08%
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, 29 Oct 2011 08:15:34 -0000





=0A




	


		

	


	


		

			


				


					

					Sign up for newsletters and offers from MSN.

                					

				


				


					

                                                                     =

                  =20

                                                
=

 3D"Click 



					                    


				




				


					

					You are receiving this e-mail because you subscribed to MSN Feature=

d Offers. Microsoft respects your privacy.  Please read our online Priva=

cy Statement.



If you would prefer to no longer receive this Featured Offer Newsletter,=

 please click the =E2=80=9CUnsubscribe=E2=80=9D link below.  This will=

 not unsubscribe you from e-mail communications from third-party adverti=

sers that may appear in MSN Featured Offers. This shall not constitute=

 an offer by MSN. MSN shall not be responsible or liable for the adverti=

sers' content nor any of the goods or service advertised. Prices and ite=

m availability subject to change without notice.  To set your contact=

 preferences for other Microsoft communications, see the communications=

 preferences section of the Microsoft Privacy Statement.





		©2010 Microsoft | Unsubscribe | M=

ore Newsletters | Privacy



		Microsoft Corporation, One Microsoft Way, Redmond, WA 98052



               =20



							

				


		


				

	










From swmike@swm.pp.se  Sat Oct 29 01:38: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 BCB0B21F899F for ; Sat, 29 Oct 2011 01:38:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.439
X-Spam-Level: 
X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[AWL=0.160,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLKyPPkEXv0I for ; Sat, 29 Oct 2011 01:38:07 -0700 (PDT)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id ACDA421F899D for ; Sat, 29 Oct 2011 01:38:03 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id C74159E; Sat, 29 Oct 2011 10:38:01 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id C2C849A for ; Sat, 29 Oct 2011 10:38:01 +0200 (CEST)
Date: Sat, 29 Oct 2011 10:38:01 +0200 (CEST)
From: Mikael Abrahamsson 
To: "behave@ietf.org" 
In-Reply-To: <412F66EB-9ADF-448D-9324-582F2D0B9AFD@cisco.com>
Message-ID: 
References:  <412F66EB-9ADF-448D-9324-582F2D0B9AFD@cisco.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Subject: Re: [BEHAVE] CGN Requirements: logging (draft-ietf-behave-lsn-requirements)
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, 29 Oct 2011 08:38:07 -0000

On Fri, 28 Oct 2011, Benson Schliesser wrote:

> My opinion is that if we say that a CGN "SHOULD" do bulk port 
> allocation, then we should also say that it "MAY" do per-connection port 
> allocation (based on the rationale I just described).  Thoughts on this?

It's my opinion that it SHOULD support both, and that this SHOULD be user 
configurable.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

From mawatari@jpix.ad.jp  Sat Oct 29 04:06: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 8023821F8A56; Sat, 29 Oct 2011 04:06:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.09
X-Spam-Level: 
X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YszZUtDM1vy5; Sat, 29 Oct 2011 04:06:20 -0700 (PDT)
Received: from mx20.jpix.ad.jp (mx20.jpix.ad.jp [210.171.225.78]) by ietfa.amsl.com (Postfix) with ESMTP id D18FC21F88A0; Sat, 29 Oct 2011 04:06:19 -0700 (PDT)
Received: from [192.168.11.3] (i60-34-9-195.s02.a013.ap.plala.or.jp [60.34.9.195]) by mx20.jpix.ad.jp (Postfix) with ESMTP id B91D7FC021; Sat, 29 Oct 2011 20:06:17 +0900 (JST)
Date: Sat, 29 Oct 2011 20:06:18 +0900
From: MAWATARI Masataka 
To: cb.list6@gmail.com
In-Reply-To: 
References: 
Message-Id: <20111029200617.386A.8FE1F57E@jpix.ad.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.57.03 [ja]
Cc: softwires@ietf.org, behave@ietf.org, draft-mawatari-softwire-464xlat@tools.ietf.org
Subject: Re: [BEHAVE] comments draft-mawatari-softwire-464xlat-01
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, 29 Oct 2011 11:06:20 -0000

Greetings Cameron-san,


Cross posting to behave.

Thank you very much for your comment and sorry for the delay.


n900ipv6 is interesting. Thank you for good information.

The CLAT necessary for function is simple and easy to implement
so the range of application of CLAT can be expanded.

I agree that 464xlat is applied to mobile network too.
I think that it can utilize a simplicity of implementation on CLAT
and adding a usecase of the mobile network to this draft is possible.


You mentioned that this method in this draft don't require DHCPv6.
I agree with you. But I think that there are other proposals must not
use DHCPv6. please let me know about your mention about this point.


Regards,
Masataka MAWATARI


* On Thu, 27 Oct 2011 13:21:51 -0700
* Cameron Byrne  wrote:

> I like the ideas in this draft.  A few comments:
> 
> 1. I think this idea of NAT464 is very applicable, especially in
> mobile networks.  There is already a similar NAT464 deployment here
> https://code.google.com/p/n900ipv6/wiki/README ....Running code,
> running architecture, running network are all proven today...   I
> think it makes sense to think of the CLAT as a mobile phone, or at
> least consider it as a use case.
> 
> 2. If we can consider the mobile network use case, it may make sense
> to broaden the scope to not exclude DNS64 and not require DHCPv6.
> Mobile networks do not generally use DHCPv6. My ideal case would be to
> allow DNS64 to facilitate as much native and single translation
> traffic as possible, while minimizing and enabling the double
> translation traffic where it is needed (IPv4 sockets, IPv4 literals,
> ...).
> 
> 3.  Since DHCPv6 is not used in mobile, it may make sense to add a
> scenario to learn the NSP PREF64 of the NAT64/DNS64 from this work
> draft-ietf-behave-nat64-discovery-heuristic-03
> 
> 4.  So, adding a mobile scenario would be to have CLAT in the phone,
> DNS64 and NAT64 in the network, and CLAT does
> draft-ietf-behave-nat64-discovery-heuristic-03 to discover NSP.  I
> believe this solves an important problem for mobile phone and mobile
> networks that must go IPv6-only.  Today, NAT64/DNS64 on mobile phones
> work well, but there is a small minority of applications that cannot
> work, and this N900 code i showed above has proven to overcome these
> limitations.  I believe this draft can provide a generic frame work
> for mobile as well as fixed-line that works well if we slightly
> increase the scope as mentioned above.
> 
> 5.  Finally, i think this work should be moved to BEHAVE.  AFAIK,
> BEHAVE is not closed and BEHAVE is the right space for this
> architectural work that uses the BEHAVE standards.
> 
> Cameron

-- 
Japan Internet Exchange
MAWATARI Masataka 
tel:+81-3-3243-9579


From mawatari@jpix.ad.jp  Sat Oct 29 05:43: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 4D34F21F891D; Sat, 29 Oct 2011 05:43:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.09
X-Spam-Level: 
X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWOOiq5Mw7R5; Sat, 29 Oct 2011 05:43:13 -0700 (PDT)
Received: from mx20.jpix.ad.jp (mx20.jpix.ad.jp [210.171.225.78]) by ietfa.amsl.com (Postfix) with ESMTP id 9E3FC21F8906; Sat, 29 Oct 2011 05:43:13 -0700 (PDT)
Received: from [192.168.11.3] (i60-34-9-195.s02.a013.ap.plala.or.jp [60.34.9.195]) by mx20.jpix.ad.jp (Postfix) with ESMTP id E2190FC021; Sat, 29 Oct 2011 21:43:09 +0900 (JST)
Date: Sat, 29 Oct 2011 21:43:10 +0900
From: MAWATARI Masataka 
To: cb.list6@gmail.com
In-Reply-To: <20111029200617.386A.8FE1F57E@jpix.ad.jp>
References:  <20111029200617.386A.8FE1F57E@jpix.ad.jp>
Message-Id: <20111029214309.3871.8FE1F57E@jpix.ad.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.57.03 [ja]
Cc: softwires@ietf.org, behave@ietf.org, draft-mawatari-softwire-464xlat@tools.ietf.org
Subject: Re: [BEHAVE] [Softwires] comments draft-mawatari-softwire-464xlat-01
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, 29 Oct 2011 12:43:14 -0000

Greetings Cameron-san,


* On Sat, 29 Oct 2011 20:06:18 +0900
* MAWATARI Masataka  wrote:

> Greetings Cameron-san,
> 
> 
> Cross posting to behave.
> 
> Thank you very much for your comment and sorry for the delay.
> 
> 
> n900ipv6 is interesting. Thank you for good information.
> 
> The CLAT necessary for function is simple and easy to implement
> so the range of application of CLAT can be expanded.
> 
> I agree that 464xlat is applied to mobile network too.
> I think that it can utilize a simplicity of implementation on CLAT
> and adding a usecase of the mobile network to this draft is possible.
> 
> 
> You mentioned that this method in this draft don't require DHCPv6.
> I agree with you. But I think that there are other proposals must not
> use DHCPv6. please let me know about your mention about this point.


I'm sorry... I made a mistake.
I meant to say "I think that there are other proposals don't require
DHCPv6".


Kind Regards,
Masataka MAWATARI


> * On Thu, 27 Oct 2011 13:21:51 -0700
> * Cameron Byrne  wrote:
> 
> > I like the ideas in this draft.  A few comments:
> > 
> > 1. I think this idea of NAT464 is very applicable, especially in
> > mobile networks.  There is already a similar NAT464 deployment here
> > https://code.google.com/p/n900ipv6/wiki/README ....Running code,
> > running architecture, running network are all proven today...   I
> > think it makes sense to think of the CLAT as a mobile phone, or at
> > least consider it as a use case.
> > 
> > 2. If we can consider the mobile network use case, it may make sense
> > to broaden the scope to not exclude DNS64 and not require DHCPv6.
> > Mobile networks do not generally use DHCPv6. My ideal case would be to
> > allow DNS64 to facilitate as much native and single translation
> > traffic as possible, while minimizing and enabling the double
> > translation traffic where it is needed (IPv4 sockets, IPv4 literals,
> > ...).
> > 
> > 3.  Since DHCPv6 is not used in mobile, it may make sense to add a
> > scenario to learn the NSP PREF64 of the NAT64/DNS64 from this work
> > draft-ietf-behave-nat64-discovery-heuristic-03
> > 
> > 4.  So, adding a mobile scenario would be to have CLAT in the phone,
> > DNS64 and NAT64 in the network, and CLAT does
> > draft-ietf-behave-nat64-discovery-heuristic-03 to discover NSP.  I
> > believe this solves an important problem for mobile phone and mobile
> > networks that must go IPv6-only.  Today, NAT64/DNS64 on mobile phones
> > work well, but there is a small minority of applications that cannot
> > work, and this N900 code i showed above has proven to overcome these
> > limitations.  I believe this draft can provide a generic frame work
> > for mobile as well as fixed-line that works well if we slightly
> > increase the scope as mentioned above.
> > 
> > 5.  Finally, i think this work should be moved to BEHAVE.  AFAIK,
> > BEHAVE is not closed and BEHAVE is the right space for this
> > architectural work that uses the BEHAVE standards.
> > 
> > Cameron

-- 
Japan Internet Exchange
MAWATARI Masataka 
tel:+81-3-3243-9579


From petithug@acm.org  Sat Oct 29 16:23: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 8563821F84D4; Sat, 29 Oct 2011 16:23:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.243
X-Spam-Level: 
X-Spam-Status: No, score=-102.243 tagged_above=-999 required=5 tests=[AWL=0.357, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KEct+xyomWsw; Sat, 29 Oct 2011 16:23:15 -0700 (PDT)
Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id C4E0021F84D3; Sat, 29 Oct 2011 16:23:15 -0700 (PDT)
Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 5E28D2087B; Sat, 29 Oct 2011 23:14:38 +0000 (UTC)
Message-ID: <4EAC8AE0.3020307@acm.org>
Date: Sat, 29 Oct 2011 16:23:12 -0700
From: Marc Petit-Huguenin 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111010 Iceowl/1.0b2 Icedove/3.1.15
MIME-Version: 1.0
To: Harald Alvestrand 
References: <4EAC6BF4.2000604@alvestrand.no> 
In-Reply-To: 
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Cc: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , "rtcweb@ietf.org" , Behave WG 
Subject: Re: [BEHAVE] [rtcweb] URI schemes for TURN and STUN
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, 29 Oct 2011 23:23:16 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/29/2011 03:36 PM, Iñaki Baz Castillo wrote:
> 2011/10/29 Harald Alvestrand :
>> - I do not think it's appropriate to use "turn" and "turns" for indicating
>> transport. Polluting the URI namespace with more configuration parameters in
>> the form of trailing "s" is a Bad Thing.
> 
> But there should be some way to indicate that a TURN server listens in
> TLS, right?
> 

We should continue this discussion in BEHAVE, but I would like to ask the OP to
send a pointer on the RFC or discussion that says that using a trailing "s" to
indicate security is a bad thing.

Thanks.

- -- 
Marc Petit-Huguenin
Personal email: marc@petit-huguenin.org
Professional email: petithug@acm.org
Blog: http://blog.marc.petit-huguenin.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk6sit4ACgkQ9RoMZyVa61dhpgCfZv+XuDhAljo3N0s33zbh6l0E
aWAAmwUP2mvcZiY9BLB5BAsjoe6OULMl
=yx3i
-----END PGP SIGNATURE-----

From moore@network-heretics.com  Sat Oct 29 21:44: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 6695E21F8487; Sat, 29 Oct 2011 21:44:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.276
X-Spam-Level: 
X-Spam-Status: No, score=-3.276 tagged_above=-999 required=5 tests=[AWL=0.323,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Y93jmFs3Tj7; Sat, 29 Oct 2011 21:44:25 -0700 (PDT)
Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 649D721F8486; Sat, 29 Oct 2011 21:44:25 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 1E0BA20A70; Sun, 30 Oct 2011 00:44:24 -0400 (EDT)
Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute2.internal (MEProxy); Sun, 30 Oct 2011 00:44:24 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=T0INK1107QFmAjFeBiycaoP3OOs=; b=Dk zNGoC2CH0wBrzNYW/vqJnze8g+YmMKHPd9Z8ttAwiKkPo4DT+58V+XrBBCpM9TdA wBqu0gnGgA1d4KawMimjkQcpbTouY2Oym16//q5Kplq/xNyq7SLvJ5a6/co9LeFV +HyhuyFQ2prE2e5OqAvdp8ts5Ijh3oD7pQHAqJTHY=
X-Sasl-enc: Bncb10QD0JjKA1yCoLVL11zmCKxfgGcoXnVksA2Odtzm 1319949863
Received: from [192.168.1.16] (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 900C58E0FB3; Sun, 30 Oct 2011 00:44:22 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: Keith Moore 
In-Reply-To: <4EACD558.1050003@alvestrand.no>
Date: Sun, 30 Oct 2011 00:44:21 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <8E6C5B0D-2161-4D14-9BEE-7B41998CDB7E@network-heretics.com>
References: <4EAC6BF4.2000604@alvestrand.no>  <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no>
To: Harald Alvestrand 
X-Mailer: Apple Mail (2.1084)
Cc: Ned Freed , =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , Keith Moore , "rtcweb@ietf.org" , Behave WG 
Subject: Re: [BEHAVE] [rtcweb] URI schemes for TURN and STUN
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, 30 Oct 2011 04:44:26 -0000

On Oct 30, 2011, at 12:40 AM, Harald Alvestrand wrote:

> On 10/29/2011 04:23 PM, Marc Petit-Huguenin wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>=20
>> On 10/29/2011 03:36 PM, I=F1aki Baz Castillo wrote:
>>> 2011/10/29 Harald Alvestrand:
>>>> - I do not think it's appropriate to use "turn" and "turns" for =
indicating
>>>> transport. Polluting the URI namespace with more configuration =
parameters in
>>>> the form of trailing "s" is a Bad Thing.
>>> But there should be some way to indicate that a TURN server listens =
in
>>> TLS, right?
>>>=20
>> We should continue this discussion in BEHAVE, but I would like to ask =
the OP to
>> send a pointer on the RFC or discussion that says that using a =
trailing "s" to
>> indicate security is a bad thing.
> I'll have to forward this question to the apps ADs of a few years ago =
about whether there's documentation for it. It does not seem to have =
been captured in an RFC that I can find; discussion was in the =
~2000-2005 timeframe.
>=20
> The short version, from memory: Doing "s" locks you into one and =
exactly one security scheme, and prevents you from saying anything about =
the requisite parameters for that scheme, while using AUTH parameters =
such as POP or in-band negotiation such as IMAP  are much more flexible =
approaches.

Security schemes change over time as new (presumably better) ones =
appear, and vulnerabilities are discovered in old ones.   There's =
nothing inherently wrong with having a URI scheme end in "s".  But it's =
a Bad Idea to promote the notion that "s" means "security".

Keith


From petithug@acm.org  Sun Oct 30 08:34: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 E335321F8569 for ; Sun, 30 Oct 2011 08:34:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.652
X-Spam-Level: 
X-Spam-Status: No, score=-101.652 tagged_above=-999 required=5 tests=[AWL=-0.269, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, RCVD_IN_PBL=0.905, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66A4W0YpEEyg for ; Sun, 30 Oct 2011 08:34:38 -0700 (PDT)
Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA8F21F84BC for ; Sun, 30 Oct 2011 08:34:38 -0700 (PDT)
Received: from [192.168.42.25] (mfd0536d0.tmodns.net [208.54.5.253]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 7797720371; Sun, 30 Oct 2011 15:25:57 +0000 (UTC)
Message-ID: <4EAD6E87.6000508@acm.org>
Date: Sun, 30 Oct 2011 11:34:31 -0400
From: Marc Petit-Huguenin 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111010 Icedove/3.1.15
MIME-Version: 1.0
To: Keith Moore 
References: <4EAC6BF4.2000604@alvestrand.no>  <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <8E6C5B0D-2161-4D14-9BEE-7B41998CDB7E@network-heretics.com>
In-Reply-To: <8E6C5B0D-2161-4D14-9BEE-7B41998CDB7E@network-heretics.com>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Cc: Keith Moore , Harald Alvestrand , Behave WG , Ned Freed , =?UTF-8?B?ScOxYWtpIEJheiBDYQ==?= =?UTF-8?B?c3RpbGxv?= 
Subject: Re: [BEHAVE] [rtcweb] URI schemes for TURN and STUN
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, 30 Oct 2011 15:34:43 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/30/2011 12:44 AM, Keith Moore wrote:
> 
> On Oct 30, 2011, at 12:40 AM, Harald Alvestrand wrote:
> 
>> On 10/29/2011 04:23 PM, Marc Petit-Huguenin wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On 10/29/2011 03:36 PM, Iñaki Baz Castillo wrote:
>>>> 2011/10/29 Harald Alvestrand:
>>>>> - I do not think it's appropriate to use "turn" and "turns" for indicating
>>>>> transport. Polluting the URI namespace with more configuration parameters in
>>>>> the form of trailing "s" is a Bad Thing.
>>>> But there should be some way to indicate that a TURN server listens in
>>>> TLS, right?
>>>>
>>> We should continue this discussion in BEHAVE, but I would like to ask the OP to
>>> send a pointer on the RFC or discussion that says that using a trailing "s" to
>>> indicate security is a bad thing.
>> I'll have to forward this question to the apps ADs of a few years ago about whether there's documentation for it. It does not seem to have been captured in an RFC that I can find; discussion was in the ~2000-2005 timeframe.
>>
>> The short version, from memory: Doing "s" locks you into one and exactly one security scheme, and prevents you from saying anything about the requisite parameters for that scheme, while using AUTH parameters such as POP or in-band negotiation such as IMAP  are much more flexible approaches.
> 
> Security schemes change over time as new (presumably better) ones appear, and vulnerabilities are discovered in old ones.   There's nothing inherently wrong with having a URI scheme end in "s".  But it's a Bad Idea to promote the notion that "s" means "security".
> 

I understand the "s" suffix as meaning "the transport to the next app level hop
MUST be secure", which actually means TLS, but it could be anything else.  I
agree that it would have been a better idea to define a scheme separator like in
[1], to not have to register multiple schemes (i.e. "sip+s:", "http+s:",
"turn+s:", etc...).  Similarly, one can define a suffix (say +sec) that means
e2e security like in [2].  That would give "sip+sec:" for e2e SIP security, and
"turn+sec:" for a secure transport and allocation.


[1] http://tools.ietf.org/html/draft-wood-tae-specifying-uri-transports
[2] http://tools.ietf.org/html/draft-gurbani-sip-sipsec

- -- 
Marc Petit-Huguenin
Personal email: marc@petit-huguenin.org
Professional email: petithug@acm.org
Blog: http://blog.marc.petit-huguenin.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk6tboMACgkQ9RoMZyVa61eTTACgoDKJ5LQ1KFwFH1Epnc2x/iH4
x90AoJ+ogURbCcw682se9lj+luF1gQgs
=MfbQ
-----END PGP SIGNATURE-----

From moore@network-heretics.com  Sun Oct 30 09:02:18 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 CA22521F8B43 for ; Sun, 30 Oct 2011 09:02:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.286
X-Spam-Level: 
X-Spam-Status: No, score=-3.286 tagged_above=-999 required=5 tests=[AWL=0.313,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikF1JRIAJWC9 for ; Sun, 30 Oct 2011 09:02:18 -0700 (PDT)
Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA9421F8B40 for ; Sun, 30 Oct 2011 09:02:16 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 7B5C9212B5; Sun, 30 Oct 2011 12:02:15 -0400 (EDT)
Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute4.internal (MEProxy); Sun, 30 Oct 2011 12:02:15 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=HUMIYu7bZrRdZ2MGnF5oAdSXToI=; b=b8 jPKL6+sfBBnjjn+J3xPzbNLDTdcWZgIRgUZOOim8/M3EI4EF6N5mZ9tz+FEWid+/ zPjveQhJP0HHmitTJuf/FCt+TcKjTETTK1tPpvJdvXNZFwaf8GxMwcce55SPTUvX LcUSkLA8QV9WP1/3pf19VDBQqNO8i1XX4r1xb8VkI=
X-Sasl-enc: jF6VoD6iLUHD/23SuTScWktHBCQF1W9c0MEHW0IbwwjJ 1319990535
Received: from [192.168.1.16] (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 41B498E0FC1; Sun, 30 Oct 2011 12:02:14 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Keith Moore 
In-Reply-To: <4EAD6E87.6000508@acm.org>
Date: Sun, 30 Oct 2011 12:02:13 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <26712529-5B8E-4352-B314-6B06135DC4BF@network-heretics.com>
References: <4EAC6BF4.2000604@alvestrand.no>  <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <8E6C5B0D-2161-4D14-9BEE-7B41998CDB7E@network-heretics.com> <4EAD6E87.6000508@acm.org>
To: Marc Petit-Huguenin 
X-Mailer: Apple Mail (2.1084)
Cc: Keith Moore , Harald Alvestrand , Behave WG , Ned Freed , =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= 
Subject: Re: [BEHAVE] [rtcweb] URI schemes for TURN and STUN
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, 30 Oct 2011 16:02:18 -0000

On Oct 30, 2011, at 11:34 AM, Marc Petit-Huguenin wrote:

>> Security schemes change over time as new (presumably better) ones =
appear, and vulnerabilities are discovered in old ones.   There's =
nothing inherently wrong with having a URI scheme end in "s".  But it's =
a Bad Idea to promote the notion that "s" means "security".
>>=20
>=20
> I understand the "s" suffix as meaning "the transport to the next app =
level hop
> MUST be secure", which actually means TLS, but it could be anything =
else.

The fact that people "understand" this is a good reason to stop using =
this convention.

All of the examples of the "s" suffix that I'm aware of originally used =
SSL.   "https" could be understood as an abbreviation for "HTTP over =
SSL".

Keith



From harald@alvestrand.no  Sun Oct 30 09:04: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 8723721F8B4A for ; Sun, 30 Oct 2011 09:04:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.549
X-Spam-Level: 
X-Spam-Status: No, score=-110.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uT8Oly-wzscN for ; Sun, 30 Oct 2011 09:04:19 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1B721F8B47 for ; Sun, 30 Oct 2011 09:04:19 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5570E39E088; Sun, 30 Oct 2011 17:04:18 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zykzgMtoga92; Sun, 30 Oct 2011 17:04:17 +0100 (CET)
Received: from [192.168.6.21] (unknown [24.104.44.194]) by eikenes.alvestrand.no (Postfix) with ESMTPS id DB80839E038; Sun, 30 Oct 2011 17:04:15 +0100 (CET)
Message-ID: <4EAD757F.7020304@alvestrand.no>
Date: Sun, 30 Oct 2011 09:04:15 -0700
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15
MIME-Version: 1.0
To: Marc Petit-Huguenin 
References: <4EAC6BF4.2000604@alvestrand.no>  <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <8E6C5B0D-2161-4D14-9BEE-7B41998CDB7E@network-heretics.com> <4EAD6E87.6000508@acm.org>
In-Reply-To: <4EAD6E87.6000508@acm.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: Keith Moore , =?UTF-8?B?ScOxYWtpIEJheiBDYQ==?= =?UTF-8?B?c3RpbGxv?= , Behave WG , Keith Moore , Ned Freed 
Subject: Re: [BEHAVE] [rtcweb] URI schemes for TURN and STUN
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, 30 Oct 2011 16:04:20 -0000

On 10/30/2011 08:34 AM, Marc Petit-Huguenin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 10/30/2011 12:44 AM, Keith Moore wrote:
>> On Oct 30, 2011, at 12:40 AM, Harald Alvestrand wrote:
>>
>>> On 10/29/2011 04:23 PM, Marc Petit-Huguenin wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> On 10/29/2011 03:36 PM, Iñaki Baz Castillo wrote:
>>>>> 2011/10/29 Harald Alvestrand:
>>>>>> - I do not think it's appropriate to use "turn" and "turns" for indicating
>>>>>> transport. Polluting the URI namespace with more configuration parameters in
>>>>>> the form of trailing "s" is a Bad Thing.
>>>>> But there should be some way to indicate that a TURN server listens in
>>>>> TLS, right?
>>>>>
>>>> We should continue this discussion in BEHAVE, but I would like to ask the OP to
>>>> send a pointer on the RFC or discussion that says that using a trailing "s" to
>>>> indicate security is a bad thing.
>>> I'll have to forward this question to the apps ADs of a few years ago about whether there's documentation for it. It does not seem to have been captured in an RFC that I can find; discussion was in the ~2000-2005 timeframe.
>>>
>>> The short version, from memory: Doing "s" locks you into one and exactly one security scheme, and prevents you from saying anything about the requisite parameters for that scheme, while using AUTH parameters such as POP or in-band negotiation such as IMAP  are much more flexible approaches.
>> Security schemes change over time as new (presumably better) ones appear, and vulnerabilities are discovered in old ones.   There's nothing inherently wrong with having a URI scheme end in "s".  But it's a Bad Idea to promote the notion that "s" means "security".
>>
> I understand the "s" suffix as meaning "the transport to the next app level hop
> MUST be secure", which actually means TLS, but it could be anything else.
err..... TLS with a NULL cipher and no certification checking is NOT secure.
Neither is TLS with 40-bit RC4, although it takes a little effort to 
break (CPU-minutes).
>    I
> agree that it would have been a better idea to define a scheme separator like in
> [1], to not have to register multiple schemes (i.e. "sip+s:", "http+s:",
> "turn+s:", etc...).  Similarly, one can define a suffix (say +sec) that means
> e2e security like in [2].  That would give "sip+sec:" for e2e SIP security, and
> "turn+sec:" for a secure transport and allocation.
If we need to indicate security functionality requirements in the URL (a 
doubtful proposition), I think the better solution is

:;auth=cert;crypt=tls

or someting like that (with suitable profiling for those values)

In TURN's case, we have exactly 3 currently defined operational modes, 
which require you to know which one to select before you start 
connecting, so

turn://user@host;mode=

seems like a reasonable thing to do.

Reading security as a binary "either it's secure or it's not" is usually 
not a sign that the requirements for the situation have been deeply 
analyzed.

>
> [1] http://tools.ietf.org/html/draft-wood-tae-specifying-uri-transports
> [2] http://tools.ietf.org/html/draft-gurbani-sip-sipsec
>
> - -- 
> Marc Petit-Huguenin
> Personal email: marc@petit-huguenin.org
> Professional email: petithug@acm.org
> Blog: http://blog.marc.petit-huguenin.org
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iEYEARECAAYFAk6tboMACgkQ9RoMZyVa61eTTACgoDKJ5LQ1KFwFH1Epnc2x/iH4
> x90AoJ+ogURbCcw682se9lj+luF1gQgs
> =MfbQ
> -----END PGP SIGNATURE-----
>


From ibc@aliax.net  Sat Oct 29 16: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 C958311E8080; Sat, 29 Oct 2011 16:26:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.644
X-Spam-Level: 
X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=0.033,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EuZ2zQ1h8WGB; Sat, 29 Oct 2011 16:26:27 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 296CD11E807F; Sat, 29 Oct 2011 16:26:27 -0700 (PDT)
Received: by vcbfo1 with SMTP id fo1so4965523vcb.31 for ; Sat, 29 Oct 2011 16:26:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.150.81 with SMTP id x17mr1410465vcv.233.1319930785403; Sat, 29 Oct 2011 16:26:25 -0700 (PDT)
Received: by 10.220.184.6 with HTTP; Sat, 29 Oct 2011 16:26:25 -0700 (PDT)
In-Reply-To: <4EAC8AE0.3020307@acm.org>
References: <4EAC6BF4.2000604@alvestrand.no>  <4EAC8AE0.3020307@acm.org>
Date: Sun, 30 Oct 2011 01:26:25 +0200
Message-ID: 
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
To: Marc Petit-Huguenin 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Sun, 30 Oct 2011 13:51:56 -0700
Cc: Harald Alvestrand , "rtcweb@ietf.org" , Behave WG 
Subject: Re: [BEHAVE] [rtcweb] URI schemes for TURN and STUN
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, 29 Oct 2011 23:26:27 -0000

2011/10/30 Marc Petit-Huguenin :
> I would like to ask the OP to
> send a pointer on the RFC or discussion that says that using a trailing "=
s" to
> indicate security is a bad thing.

Well, in http (so https) it's a good idea.
In SIP (using "sips" instead of "sip" schema) it's a pain nobody wants
to deal with (and there are bugs in the specifications).

--=20
I=C3=B1aki Baz Castillo


From harald@alvestrand.no  Sat Oct 29 21:41: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 1CCC411E8083; Sat, 29 Oct 2011 21:41:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.524
X-Spam-Level: 
X-Spam-Status: No, score=-110.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmeszXy7rRcr; Sat, 29 Oct 2011 21:41:01 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 2198D11E8082; Sat, 29 Oct 2011 21:41:01 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3228139E162; Sun, 30 Oct 2011 05:41:00 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6lPh-Opdjpx; Sun, 30 Oct 2011 05:40:59 +0100 (CET)
Received: from [192.168.6.21] (unknown [24.104.44.194]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 05BD939E088; Sun, 30 Oct 2011 05:40:57 +0100 (CET)
Message-ID: <4EACD558.1050003@alvestrand.no>
Date: Sat, 29 Oct 2011 21:40:56 -0700
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15
MIME-Version: 1.0
To: Marc Petit-Huguenin 
References: <4EAC6BF4.2000604@alvestrand.no>  <4EAC8AE0.3020307@acm.org>
In-Reply-To: <4EAC8AE0.3020307@acm.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Mailman-Approved-At: Sun, 30 Oct 2011 13:51:56 -0700
Cc: Keith Moore , =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , "rtcweb@ietf.org" , Ned Freed , Behave WG 
Subject: Re: [BEHAVE] [rtcweb] URI schemes for TURN and STUN
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, 30 Oct 2011 04:41:02 -0000

On 10/29/2011 04:23 PM, Marc Petit-Huguenin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 10/29/2011 03:36 PM, Iñaki Baz Castillo wrote:
>> 2011/10/29 Harald Alvestrand:
>>> - I do not think it's appropriate to use "turn" and "turns" for indicating
>>> transport. Polluting the URI namespace with more configuration parameters in
>>> the form of trailing "s" is a Bad Thing.
>> But there should be some way to indicate that a TURN server listens in
>> TLS, right?
>>
> We should continue this discussion in BEHAVE, but I would like to ask the OP to
> send a pointer on the RFC or discussion that says that using a trailing "s" to
> indicate security is a bad thing.
I'll have to forward this question to the apps ADs of a few years ago 
about whether there's documentation for it. It does not seem to have 
been captured in an RFC that I can find; discussion was in the 
~2000-2005 timeframe.

The short version, from memory: Doing "s" locks you into one and exactly 
one security scheme, and prevents you from saying anything about the 
requisite parameters for that scheme, while using AUTH parameters such 
as POP or in-band negotiation such as IMAP  are much more flexible 
approaches.


> Thanks.
>
> - -- 
> Marc Petit-Huguenin
> Personal email: marc@petit-huguenin.org
> Professional email: petithug@acm.org
> Blog: http://blog.marc.petit-huguenin.org
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iEYEARECAAYFAk6sit4ACgkQ9RoMZyVa61dhpgCfZv+XuDhAljo3N0s33zbh6l0E
> aWAAmwUP2mvcZiY9BLB5BAsjoe6OULMl
> =yx3i
> -----END PGP SIGNATURE-----
>


From ekr@rtfm.com  Sun Oct 30 07:29:38 2011
Return-Path: 
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81FB921F8497; Sun, 30 Oct 2011 07:29:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.96
X-Spam-Level: 
X-Spam-Status: No, score=-102.96 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0moZTEPPc0vH; Sun, 30 Oct 2011 07:29:38 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id D6F7721F8495; Sun, 30 Oct 2011 07:29:37 -0700 (PDT)
Received: by ggnv1 with SMTP id v1so6040520ggn.31 for ; Sun, 30 Oct 2011 07:29:37 -0700 (PDT)
Received: by 10.236.77.163 with SMTP id d23mr12446161yhe.34.1319984977447; Sun, 30 Oct 2011 07:29:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.147.124.3 with HTTP; Sun, 30 Oct 2011 07:28:56 -0700 (PDT)
In-Reply-To: <4EACD558.1050003@alvestrand.no>
References: <4EAC6BF4.2000604@alvestrand.no>  <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no>
From: Eric Rescorla 
Date: Sun, 30 Oct 2011 07:28:56 -0700
Message-ID: 
To: Harald Alvestrand 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Sun, 30 Oct 2011 13:51:56 -0700
Cc: Keith Moore , Ned Freed , Behave WG , "rtcweb@ietf.org" 
Subject: Re: [BEHAVE] [rtcweb] URI schemes for TURN and STUN
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, 30 Oct 2011 14:29:38 -0000

On Sat, Oct 29, 2011 at 9:40 PM, Harald Alvestrand  w=
rote:
> On 10/29/2011 04:23 PM, Marc Petit-Huguenin wrote:
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 10/29/2011 03:36 PM, I=F1aki Baz Castillo wrote:
>>>
>>> 2011/10/29 Harald Alvestrand:
>>>>
>>>> - I do not think it's appropriate to use "turn" and "turns" for
>>>> indicating
>>>> transport. Polluting the URI namespace with more configuration
>>>> parameters in
>>>> the form of trailing "s" is a Bad Thing.
>>>
>>> But there should be some way to indicate that a TURN server listens in
>>> TLS, right?
>>>
>> We should continue this discussion in BEHAVE, but I would like to ask th=
e
>> OP to
>> send a pointer on the RFC or discussion that says that using a trailing
>> "s" to
>> indicate security is a bad thing.
>
> I'll have to forward this question to the apps ADs of a few years ago abo=
ut
> whether there's documentation for it. It does not seem to have been captu=
red
> in an RFC that I can find; discussion was in the ~2000-2005 timeframe.
>
> The short version, from memory: Doing "s" locks you into one and exactly =
one
> security scheme, and prevents you from saying anything about the requisit=
e
> parameters for that scheme, while using AUTH parameters such as POP or
> in-band negotiation such as IMAP =A0are much more flexible approaches.

I haven't formed an opinion on the value of turn[s] URIs one way or
another, but...

What you say above is absolutely true, but there is a tradeoff here. If you=
 just
provide a URI with no indication of the expected security mechanism, and
rely on in-band negotiation, then an active attacker can force the client d=
own
to the weakest security mechanism (a downgrade attack). So, for instance,
if the client supports both TURN and TURN over TLS, the attacker can
impersonate a server which supports only TURN and force the client
to accept that. By contrast, if the URI indicates a minimal security
mechanism that is
sufficiently strong, then this form of attack is not possible. Obviously, t=
he
user could configure his client to only support secure connections
(via whatever mechanism) but this is less convenient.

Another point in the design space is to require some specific security mech=
anism
that is strong enough to authenticate the server and then use that mechanis=
m
to support secure negotiation of the real mechanism. Unfortunately, the onl=
y
widely supported mechanism that meets that standard is TLS, so this isn't
much of an improvement.

-Ekr

From ibc@aliax.net  Sun Oct 30 12:10: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 98FFB21F8AE6 for ; Sun, 30 Oct 2011 12:10:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.644
X-Spam-Level: 
X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=0.033,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOGGCIuBmxW0 for ; Sun, 30 Oct 2011 12:10:26 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 037A321F8AD3 for ; Sun, 30 Oct 2011 12:09:56 -0700 (PDT)
Received: by vcbfo1 with SMTP id fo1so5255692vcb.31 for ; Sun, 30 Oct 2011 12:09:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.7.12 with SMTP id b12mr2020851vcb.23.1320001796321; Sun, 30 Oct 2011 12:09:56 -0700 (PDT)
Received: by 10.220.184.6 with HTTP; Sun, 30 Oct 2011 12:09:56 -0700 (PDT)
In-Reply-To: <4EAD6E87.6000508@acm.org>
References: <4EAC6BF4.2000604@alvestrand.no>  <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <8E6C5B0D-2161-4D14-9BEE-7B41998CDB7E@network-heretics.com> <4EAD6E87.6000508@acm.org>
Date: Sun, 30 Oct 2011 20:09:56 +0100
Message-ID: 
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
To: Marc Petit-Huguenin 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Sun, 30 Oct 2011 13:51:56 -0700
Cc: Keith Moore , Harald Alvestrand , Behave WG , Keith Moore , Ned Freed 
Subject: Re: [BEHAVE] [rtcweb] URI schemes for TURN and STUN
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, 30 Oct 2011 19:10:27 -0000

2011/10/30 Marc Petit-Huguenin :
> I understand the "s" suffix as meaning "the transport to the next app lev=
el hop
> MUST be secure", which actually means TLS, but it could be anything else.=
 =C2=A0I
> agree that it would have been a better idea to define a scheme separator =
like in
> [1], to not have to register multiple schemes (i.e. "sip+s:", "http+s:",
> "turn+s:", etc...). =C2=A0Similarly, one can define a suffix (say +sec) t=
hat means
> e2e security like in [2]. =C2=A0That would give "sip+sec:" for e2e SIP se=
curity, and
> "turn+sec:" for a secure transport and allocation.

Using "sips" in SIP has been a very bad idea, not just because the
spec is unfeasible (yes, there are bugs and things that are impossible
to achieve) bu also because SIP defines URI for users, not just for
servers (as HTTP does). So when you (sip:alice@example.org) receive a
call from "sips:bob@example.org", must you consider he is the same as
"sip:bib@example.org"? What about if you set presence watching
permissions (via XCAP) to "sip:bob@example.org" but receive a presence
request from "sips:bob@example.org"? is it the msae? These are open
questions with hard response. Nowadays NOBODY use "sips" schema, so
adding more schemas (as "sip+sec") is still a vworse idea.

--=20
I=C3=B1aki Baz Castillo


From mohamed.boucadair@orange.com  Mon Oct 31 07:53: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 1841B21F8CC5 for ; Mon, 31 Oct 2011 07:53:47 -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.149,  BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYa4vWDvi-Ab for ; Mon, 31 Oct 2011 07:53:46 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 1D24521F8C63 for ; Mon, 31 Oct 2011 07:53:45 -0700 (PDT)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id A141A324403 for ; Mon, 31 Oct 2011 15:53:44 +0100 (CET)
Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 822ED4C069; Mon, 31 Oct 2011 15:53:44 +0100 (CET)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.14]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Mon, 31 Oct 2011 15:53:44 +0100
From: 
To: "'behave@ietf.org'" 
Date: Mon, 31 Oct 2011 15:53:42 +0100
Thread-Topic: [BEHAVE] Implementation & Preliminary Test Results of HOST_ID TCP Option (draft-abdo-hostid-tcpopt-implementation)
Thread-Index: AcyQAPx0WWhhKoGpRre5/7mFh/5VRQAAOuMQAfaQsaA=
Message-ID: <94C682931C08B048B7A8645303FDC9F35A37B98E73@PUEXCB1B.nanterre.francetelecom.fr>
References: <94C682931C08B048B7A8645303FDC9F35A2E6EFDDC@PUEXCB1B.nanterre.francetelecom.fr>
In-Reply-To: <94C682931C08B048B7A8645303FDC9F35A2E6EFDDC@PUEXCB1B.nanterre.francetelecom.fr>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.10.31.113314
Cc: ABDO Elie RD-CORE , QUEIROZ Jaqueline RD-CORE 
Subject: Re: [BEHAVE] Implementation & Preliminary Test Results of HOST_ID TCP Option (draft-abdo-hostid-tcpopt-implementation)
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, 31 Oct 2011 14:53:47 -0000

Dear all,

An updated version of the document has been submitted. The new version incl=
udes:

* Testing results behind two commercial (branded) CPE connected to ISP netw=
orks
* HTTP testing using top10000 website
* FTP testing using 5591 FTP servers list
* Further information can be found at: http://tools.ietf.org/id/draft-abdo-=
hostid-tcpopt-implementation-01.txt

A diff is available at: https://tools.ietf.org/rfcdiff?url1=3Ddraft-abdo-ho=
stid-tcpopt-implementation-00&difftype=3D--html&submit=3DGo%21&url2=3Ddraft=
-abdo-hostid-tcpopt-implementation-01

Cheers,
Med=

From petithug@acm.org  Mon Oct 31 07:57:52 2011
Return-Path: 
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3CE421F8D9D; Mon, 31 Oct 2011 07:57:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.45
X-Spam-Level: 
X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVuj4IR0MLpK; Mon, 31 Oct 2011 07:57:52 -0700 (PDT)
Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 1E03521F8CF4; Mon, 31 Oct 2011 07:57:52 -0700 (PDT)
Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id B07D22025C; Mon, 31 Oct 2011 14:49:07 +0000 (UTC)
Message-ID: <4EAEB76B.9090304@acm.org>
Date: Mon, 31 Oct 2011 07:57:47 -0700
From: Marc Petit-Huguenin 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111010 Iceowl/1.0b2 Icedove/3.1.15
MIME-Version: 1.0
To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 
References: <4EAC6BF4.2000604@alvestrand.no>		<4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp>
In-Reply-To: <4EAE157F.5020901@it.aoyama.ac.jp>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Cc: Harald Alvestrand , Keith Moore , Ned Freed , Behave WG , "rtcweb@ietf.org" 
Subject: Re: [BEHAVE] [rtcweb] URI schemes for TURN and STUN
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, 31 Oct 2011 14:57:53 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Martin,

So I understand Roy's email as saying in fact the opposite of what Harald said,
i.e. that using an "s" suffix to signify security is a good thing.

What is your opinion on defining a generic scheme suffix (i.e. "+s" or "+sec")
that would indicate a well defined set of security properties that could apply
to any scheme, (vs the current "s" suffix where security properties has to be
defined scheme by scheme)?

Also, what would be the best place to discuss this?

Thanks.

On 10/30/2011 08:26 PM, "Martin J. Dürst" wrote:
> For the http vs. https case, there is a very good answer from Roy Fielding at
> http://lists.w3.org/Archives/Public/www-tag/2006Mar/0040.html
> 
> In essence, not distinguishing the two schemes would mean either additional
> roundtrips (assuming http is the more frequent one) or exposition of data on the
> network that was supposed to be private.
> 
> Regards,    Martin.
> 
> On 2011/10/30 13:40, Harald Alvestrand wrote:
>> On 10/29/2011 04:23 PM, Marc Petit-Huguenin wrote:
> On 10/29/2011 03:36 PM, Iñaki Baz Castillo wrote:
>>>>> 2011/10/29 Harald Alvestrand:
>>>>>> - I do not think it's appropriate to use "turn" and "turns" for
>>>>>> indicating
>>>>>> transport. Polluting the URI namespace with more configuration
>>>>>> parameters in
>>>>>> the form of trailing "s" is a Bad Thing.
>>>>> But there should be some way to indicate that a TURN server listens in
>>>>> TLS, right?
>>>>>
> We should continue this discussion in BEHAVE, but I would like to ask
> the OP to
> send a pointer on the RFC or discussion that says that using a
> trailing "s" to
> indicate security is a bad thing.
>>> I'll have to forward this question to the apps ADs of a few years ago
>>> about whether there's documentation for it. It does not seem to have
>>> been captured in an RFC that I can find; discussion was in the
>>> ~2000-2005 timeframe.
>>>
>>> The short version, from memory: Doing "s" locks you into one and exactly
>>> one security scheme, and prevents you from saying anything about the
>>> requisite parameters for that scheme, while using AUTH parameters such
>>> as POP or in-band negotiation such as IMAP are much more flexible
>>> approaches.
>>>

- -- 
Marc Petit-Huguenin
Personal email: marc@petit-huguenin.org
Professional email: petithug@acm.org
Blog: http://blog.marc.petit-huguenin.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk6ut2kACgkQ9RoMZyVa61c3WQCeJVI5ov93J+RUp9xQvcggz8uf
J8gAoJ2I4kAA1lGIOij6GTJmsbe4WEpg
=n4RK
-----END PGP SIGNATURE-----

From moore@network-heretics.com  Mon Oct 31 08:33: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 6CF1C21F8CCC; Mon, 31 Oct 2011 08:33:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.358
X-Spam-Level: 
X-Spam-Status: No, score=-2.358 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bv5cnjfPNlkg; Mon, 31 Oct 2011 08:33:36 -0700 (PDT)
Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id B730121F8CC5; Mon, 31 Oct 2011 08:33:36 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 6A398204D7; Mon, 31 Oct 2011 11:33:35 -0400 (EDT)
Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute2.internal (MEProxy); Mon, 31 Oct 2011 11:33:35 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; s=smtpout; bh=itF 7j72tstHdMFqPsNEHQk2QR1I=; b=azttSUmT1R5QWOUeOXU+jslierKy3VvbflY 95pOv2tGjTTdMrfNcgyywgI6BusS3JzqKLp3V5dYE/M41yKWNEeT+8XVHrZlDae0 Lf14wo6EodQwzangsz3a4+bpDOlfSRrwS9GgwqJjK4QT7Xn/7M3tkz8Kx6IGMYzf XL2b1ujo=
X-Sasl-enc: 5Pbm0ts8nT6g6zyZoQRs/TQZWuNTTrH/y3AKdafZ+X3z 1320075215
Received: from rlmartin.hq.corp.pbs.org (unknown [149.48.225.2]) by mail.messagingengine.com (Postfix) with ESMTPA id 040F8483432; Mon, 31 Oct 2011 11:33:35 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-32-318113624
From: Keith Moore 
In-Reply-To: <4EAEB76B.9090304@acm.org>
Date: Mon, 31 Oct 2011 11:33:33 -0400
Message-Id: <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com>
References: <4EAC6BF4.2000604@alvestrand.no>		<4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org>
To: Marc Petit-Huguenin 
X-Mailer: Apple Mail (2.1084)
Cc: Ned Freed , Harald Alvestrand , Keith Moore , Behave WG , =?iso-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= , "rtcweb@ietf.org" 
Subject: Re: [BEHAVE] [rtcweb] URI schemes for TURN and STUN
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, 31 Oct 2011 15:33:37 -0000

--Apple-Mail-32-318113624
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Oct 31, 2011, at 10:57 AM, Marc Petit-Huguenin wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
> Hi Martin,
>=20
> So I understand Roy's email as saying in fact the opposite of what =
Harald said,
> i.e. that using an "s" suffix to signify security is a good thing.
>=20
> What is your opinion on defining a generic scheme suffix (i.e. "+s" or =
"+sec")
> that would indicate a well defined set of security properties that =
could apply
> to any scheme, (vs the current "s" suffix where security properties =
has to be
> defined scheme by scheme)?


There is no "well defined set of security properties that could apply to =
any scheme".   Security properties necessarily vary depending on the way =
a resource is used, the threat model, and so forth.=20

Also, the idea that there should be a "secure" bit in a URI scheme, to =
distinguish it from the "insecure" form of a URL, doesn't make much =
sense.  You always want to use the best security that's available.  You =
don't want that to depend on the URI scheme. =20

The "s" convention was a hack to distinguish "x over SSL" from "x" for =
all of the URIs that existed before SSL was well-established, because =
those protocols didn't (then) have a way to negotiate security in-band.  =
 It made sense as a short term hack, but not as an architectural =
feature.   It's not something that we want to propagate to new URI =
types, neither in the form of an "s" suffix, nor as any other syntactic =
convention.

Keith


--Apple-Mail-32-318113624
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


-----BEGIN PGP SIGNED MESSAGE-----
Hash: =
SHA1

Hi Martin,

So I understand Roy's email as saying in =
fact the opposite of what Harald said,
i.e. that using an "s" suffix =
to signify security is a good thing.

What is your opinion on =
defining a generic scheme suffix (i.e. "+s" or "+sec")
that would =
indicate a well defined set of security properties that could =
apply
to any scheme, (vs the current "s" suffix where security =
properties has to be
defined scheme by =
scheme)?

There is no =
"well defined set of security properties that could apply to any =
scheme".   Security properties necessarily vary depending on the =
way a resource is used, the threat model, and so =
forth. 

Also, the idea that there should =
be a "secure" bit in a URI scheme, to distinguish it from the "insecure" =
form of a URL, doesn't make much sense.  You always want to =
use the best security that's available.  You don't want that to =
depend on the URI scheme.  

The "s" =
convention was a hack to distinguish "x over SSL" from "x" for all of =
the URIs that existed before SSL was well-established, because those =
protocols didn't (then) have a way to negotiate security in-band.   =
It made sense as a short term hack, but not as an architectural feature. =
  It's not something that we want to propagate to new URI types, =
neither in the form of an "s" suffix, nor as any other syntactic =
convention.

Keith

=

--Apple-Mail-32-318113624--

From duerst@it.aoyama.ac.jp  Sun Oct 30 20:27: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 1FA7211E80B2 for ; Sun, 30 Oct 2011 20:27:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.454
X-Spam-Level: 
X-Spam-Status: No, score=-99.454 tagged_above=-999 required=5 tests=[AWL=0.336, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265,  MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4zncu-Zknjc for ; Sun, 30 Oct 2011 20:27:16 -0700 (PDT)
Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 2138711E80AE for ; Sun, 30 Oct 2011 20:27:15 -0700 (PDT)
Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id p9V3R2QD023468 for ; Mon, 31 Oct 2011 12:27:02 +0900
Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 7395_16ca_3311c2fc_0370_11e1_8351_001d096c566a; Mon, 31 Oct 2011 12:27:02 +0900
Received: from [IPv6:::1] ([133.2.210.1]:50548) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Mon, 31 Oct 2011 12:27:02 +0900
Message-ID: <4EAE157F.5020901@it.aoyama.ac.jp>
Date: Mon, 31 Oct 2011 12:26:55 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Harald Alvestrand 
References: <4EAC6BF4.2000604@alvestrand.no>		<4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no>
In-Reply-To: <4EACD558.1050003@alvestrand.no>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Mailman-Approved-At: Mon, 31 Oct 2011 08:39:36 -0700
Cc: Keith Moore , Ned Freed , Behave WG , "rtcweb@ietf.org" 
Subject: Re: [BEHAVE] [rtcweb] URI schemes for TURN and STUN
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, 31 Oct 2011 03:27:17 -0000

For the http vs. https case, there is a very good answer from Roy 
Fielding at
http://lists.w3.org/Archives/Public/www-tag/2006Mar/0040.html

In essence, not distinguishing the two schemes would mean either 
additional roundtrips (assuming http is the more frequent one) or 
exposition of data on the network that was supposed to be private.

Regards,    Martin.

On 2011/10/30 13:40, Harald Alvestrand wrote:
> On 10/29/2011 04:23 PM, Marc Petit-Huguenin wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 10/29/2011 03:36 PM, Iñaki Baz Castillo wrote:
>>> 2011/10/29 Harald Alvestrand:
>>>> - I do not think it's appropriate to use "turn" and "turns" for
>>>> indicating
>>>> transport. Polluting the URI namespace with more configuration
>>>> parameters in
>>>> the form of trailing "s" is a Bad Thing.
>>> But there should be some way to indicate that a TURN server listens in
>>> TLS, right?
>>>
>> We should continue this discussion in BEHAVE, but I would like to ask
>> the OP to
>> send a pointer on the RFC or discussion that says that using a
>> trailing "s" to
>> indicate security is a bad thing.
> I'll have to forward this question to the apps ADs of a few years ago
> about whether there's documentation for it. It does not seem to have
> been captured in an RFC that I can find; discussion was in the
> ~2000-2005 timeframe.
>
> The short version, from memory: Doing "s" locks you into one and exactly
> one security scheme, and prevents you from saying anything about the
> requisite parameters for that scheme, while using AUTH parameters such
> as POP or in-band negotiation such as IMAP are much more flexible
> approaches.
>
>
>> Thanks.
>>
>> - -- Marc Petit-Huguenin
>> Personal email: marc@petit-huguenin.org
>> Professional email: petithug@acm.org
>> Blog: http://blog.marc.petit-huguenin.org
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.11 (GNU/Linux)
>>
>> iEYEARECAAYFAk6sit4ACgkQ9RoMZyVa61dhpgCfZv+XuDhAljo3N0s33zbh6l0E
>> aWAAmwUP2mvcZiY9BLB5BAsjoe6OULMl
>> =yx3i
>> -----END PGP SIGNATURE-----
>>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

From praspati@cisco.com  Mon Oct 31 09:05: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 7356121F8B82 for ; Mon, 31 Oct 2011 09:05:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.971
X-Spam-Level: 
X-Spam-Status: No, score=-8.971 tagged_above=-999 required=5 tests=[AWL=-1.628, BAYES_20=-0.74, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XlX0MPccAsS for ; Mon, 31 Oct 2011 09:05:12 -0700 (PDT)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 2758321F8B6D for ; Mon, 31 Oct 2011 09:05:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=praspati@cisco.com; l=11427; q=dns/txt; s=iport; t=1320077112; x=1321286712; h=date:subject:from:to:cc:message-id:mime-version; bh=kaJmEZ8ienfFOtTbJuI0ghMK3mAhRQdgcwOgYqZfymw=; b=MpSI3sGnlVhpy6+Sh2j74hUXvAMwFiEEJP4ld62IC0fxfXrVhUVOHuU5 DQrBpZnehLbxiBuUrZsiHwtEmF2rcTUkvyutaa3ljZE+DE2Xj8xROxra8 6hopAc/bkwIcCqsvSQ+RyfO5wEmDyIacqs9fSzNwfSczuJPJCnwDUWAJg s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAHbGrk5Io8US/2dsb2JhbABCgk2lbHyBBYFyAQEBAQMBAQEPASoxCxIBCBhVIgEOAQQLAwUJGYdolVgBnh2JAgSHVi6MCoU2hQGHMA
X-IronPort-AV: E=Sophos;i="4.69,432,1315180800"; d="scan'208,217";a="58896765"
Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-2.cisco.com with ESMTP; 31 Oct 2011 16:05:10 +0000
Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p9VG59ZH014759; Mon, 31 Oct 2011 16:05:09 GMT
Received: from xmb-bgl-41b.cisco.com ([72.163.129.217]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 31 Oct 2011 21:35:09 +0530
Received: from 10.65.74.160 ([10.65.74.160]) by XMB-BGL-41B.cisco.com ([72.163.129.217]) with Microsoft Exchange Server HTTP-DAV ;  Mon, 31 Oct 2011 16:05:08 +0000
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Mon, 31 Oct 2011 21:35:08 +0530
From: Prashanth Patil 
To: 
Message-ID: 
Thread-Topic: [BEHAVE] I-D Action: draft-wing-behave-dhcpv6-reconfigure-00.txt
Thread-Index: AcyX5tw6C8CZdCW11kOrqCN2nb1HZg==
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3402941708_5343517"
X-OriginalArrivalTime: 31 Oct 2011 16:05:09.0050 (UTC) FILETIME=[DCDAC9A0:01CC97E6]
Cc: behave@ietf.org
Subject: Re: [BEHAVE] I-D Action: draft-wing-behave-dhcpv6-reconfigure-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, 31 Oct 2011 16:05:15 -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_3402941708_5343517
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Hi Brian,=20
The idea behind the proposal is to provision a means by which traffic is
sent using IPv4 and not through the IPv6/IPv4 translator. The advantage
being that if NAT44 and NAT64 are deployed on the same network, it is
preferable to use NAT44 over NAT64 because of scale, performance and
application incompatibility issues (e.g., FTP) [RFC6384].
A "normal" DNS server does not have DNS64 capability. The IPv4-mapped
address for this "normal" server ensures that it can be reached only by
IPv4=9A. So if a host is IPv4-only, it will send a DNS query to the "normal"
server just to get the A records. If the host is dual-stack it will also
send a DNS query to the "normal" server to get both A and AAAA records. If
the destination address is an IPv4 address,=A0 dual-stack host just gets A
records but not synthesized AAAA records. So this technique will ensure tha=
t
IPv4 is preferred over the IPv6/IPv4 translator prefix and also gives nativ=
e
IPv6 higher precedence than IPv4.
If the host happens to be IPv6 only, then it cannot reach the "normal"
server because it has IPv4-mapped prefix as explained previously. So IPv6
only host can only reach DNS64 server. So this host will send the DNS query
to DNS64 to get AAAA records. Based on the destination address the host wil=
l
get IPv4-embedded IPv6 address or just the global IPv6 address.

=9ANote: From RFC 6052
=B3When presented with the IPv4-mapped prefix, current versions of Windows an=
d
Mac OS generate IPv4 packets, but will not send IPv6 packets.=B2

-Prashanth=20

On 22/10/11 6:20 AM, Brian E Carpenter wrote:
> I have a basic question. Why does this draft define a 'normal'
> DNS server as one having an IPv4-mapped IPv6 address?
>=20
> That seems like a completely *abnormal* DNS server for a dual
> stack host. A dual stack host should normally have a DNS server
> with a regular IPv6 address that will return both A and AAAA
> records if they exist. Normally the server will be dual stacked
> anyway, and will return exactly the same response whether the
> query arrives via v4 or v6.
>=20
> A DNS server which only has an IPv4 address will also return
> A and AAAA records if they exist, so there is absolutely no
> difference as far as the dual stack host is concerned anyway.
> So what is the point in using the IPv4-mapped address?
>=20
> Regards=20
> =A0=A0=A0 Brian=20
>=20
> On 2011-10-18 11:17, internet-drafts@ietf.org wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.=20
>>=20
>> =A0=A0=A0=A0Title=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : DHCPv6 Dynamic Re-Configuration
>> =A0=A0=A0=A0Author(s)=A0=A0=A0=A0=A0=A0 : Dan Wing
>> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Tirumaleswar Reddy
>> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Prashanth Patil
>> =A0=A0=A0=A0Filename=A0=A0=A0=A0=A0=A0=A0 : draft-wing-behave-dhcpv6-reconfigure-00.txt
>> =A0=A0=A0=A0Pages=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 10
>> =A0=A0=A0=A0Date=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 2011-10-17
>>=20
>> =A0=A0=A0 Some networks are expected to support IPv4-only, dual-stack, and
>> =A0=A0=A0 IPV6-only hosts at the same time.=A0 This makes prioritizing the DNS
>> =A0=A0=A0 servers for hosts tricky due to a heterogeneous mix of protocol
>> =A0=A0=A0 stacks causing optimal behavior to occur only when the host stack re=
-
>> =A0=A0=A0 initializes.=A0 The networks infrastructure is usually well equipped t=
o
>> =A0=A0=A0 be aware of single/dual-stack nature of hosts.=A0 This specification
>> =A0=A0=A0 extends DHCPv6 so that the DHCPv6 Relay Agent can dynamically
>> =A0=A0=A0 influence the priority of DNS servers provided to the host, so that
>> =A0=A0=A0 the host can use the optimal DNS server for resolution.
>>=20
>>=20
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-wing-behave-dhcpv6-reconfigure=
-00.t
>> xt=20
>>=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-wing-behave-dhcpv6-reconfigure-=
00.tx
>> t=20
>> _______________________________________________
>> I-D-Announce mailing list
>> I-D-Announce@ietf.org
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>=20
> _______________________________________________
> Behave mailing list
> Behave@ietf.org=20
> https://www.ietf.org/mailman/listinfo/behave



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



Re: [BEHAVE] I-D Action: draft-wing-behave-dhcpv6-reconfigure-00.txt=



Hi Brian, 

The idea behind the proposal is to provision a means by which traffic is se=
nt using IPv4 and not through the IPv6/IPv4 translator. The advantage being =
that if NAT44 and NAT64 are deployed on the same network, it is preferable t=
o use NAT44 over NAT64 because of scale, performance and application incompa=
tibility issues (e.g., FTP) [RFC6384]. 

A "normal" DNS server does not have DNS64 capability. The IPv4-ma=
pped address for this "normal" server ensures that it can be reach=
ed only by IPv4˚. So if a host is IPv4-only, it will send a DNS query t=
o the "normal" server just to get the A records. If the host is du=
al-stack it will also send a DNS query to the "normal" server to g=
et both A and AAAA records. If the destination address is an IPv4 address,=A0 =
dual-stack host just gets A records but not synthesized AAAA records. So thi=
s technique will ensure that IPv4 is preferred over the IPv6/IPv4 translator=
 prefix and also gives native IPv6 higher precedence than IPv4. 

If the host happens to be IPv6 only, then it cannot reach the "normal&=
quot; server because it has IPv4-mapped prefix as explained previously. So I=
Pv6 only host can only reach DNS64 server. So this host will send the DNS qu=
ery to DNS64 to get AAAA records. Based on the destination address the host =
will get IPv4-embedded IPv6 address or just the global IPv6 address. 



˚Note: From RFC 6052 

“When presented with the IPv4-mapped prefix, current versions of Wind=
ows and Mac OS generate IPv4 packets, but will not send IPv6 packets.”=
 



-Prashanth 



On 22/10/11 6:20 AM, Brian E Carpenter wrote: 


I have a basic question. Wh=
y does this draft define a 'normal' 

DNS server as one having an IPv4-mapped IPv6 address? 



That seems like a completely *abnormal* DNS server for a dual 

stack host. A dual stack host should normally have a DNS server 

with a regular IPv6 address that will return both A and AAAA 

records if they exist. Normally the server will be dual stacked 

anyway, and will return exactly the same response whether the 

query arrives via v4 or v6. 



A DNS server which only has an IPv4 address will also return 

A and AAAA records if they exist, so there is absolutely no 

difference as far as the dual stack host is concerned anyway. 

So what is the point in using the IPv4-mapped address? 



Regards 

=A0=A0=A0 Brian 



On 2011-10-18 11:17, internet-drafts@iet=
f.org wrote: 


A New Internet-Draft is ava=
ilable from the on-line Internet-Drafts directories. 



=A0=A0=A0=A0Title=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : DHCPv6 Dynamic Re-Configuration 

=A0=A0=A0=A0Author(s)=A0=A0=A0=A0=A0=A0 : Dan Wing 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Tirumaleswar Reddy 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Prashanth Patil 

=A0=A0=A0=A0Filename=A0=A0=A0=A0=A0=A0=A0 : draft-wing-behave-dhcpv6-reconfigure-00.txt 

=A0=A0=A0=A0Pages=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 10 

=A0=A0=A0=A0Date=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 2011-10-17 



=A0=A0=A0 Some networks are expected to support IPv4-only, dual-stack, and 

=A0=A0=A0 IPV6-only hosts at the same time.=A0 This makes prioritizing the DNS 

=A0=A0=A0 servers for hosts tricky due to a heterogeneous mix of protocol 

=A0=A0=A0 stacks causing optimal behavior to occur only when the host stack re- <=
BR>
=A0=A0=A0 initializes.=A0 The networks infrastructure is usually well equipped to <=
BR>
=A0=A0=A0 be aware of single/dual-stack nature of hosts.=A0 This specification 

=A0=A0=A0 extends DHCPv6 so that the DHCPv6 Relay Agent can dynamically 

=A0=A0=A0 influence the priority of DNS servers provided to the host, so that 
=A0=A0=A0 the host can use the optimal DNS server for resolution. 





A URL for this Internet-Draft is: 

http://www.ietf.org/internet-drafts/draft-wing-behave-dhcpv6-=
reconfigure-00.txt 



Internet-Drafts are also available by anonymous FTP at: 

ftp://ftp.ietf.org/internet-d=
rafts/ 



This Internet-Draft can be retrieved at: 

ftp://ftp.ietf.org/internet-drafts/draft-wing-behave-dhcpv6-re=
configure-00.txt 

_______________________________________________ 

I-D-Announce mailing list 

I-D-Announce@ietf.org 

https://www.ie=
tf.org/mailman/listinfo/i-d-announce 

Internet-Draft directories: http:=
//www.ietf.org/shadow.html 

or ftp://ftp.ietf.org/i=
etf/1shadow-sites.txt 




__________________________=
_____________________ 

Behave mailing list 

Behave@ietf.org 

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









--B_3402941708_5343517--


From ssenthil@cisco.com  Mon Oct 31 12:18: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 0C17A11E80CA for ; Mon, 31 Oct 2011 12:18:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.901
X-Spam-Level: 
X-Spam-Status: No, score=-5.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FEsoNhTJ-DGq for ; Mon, 31 Oct 2011 12:18:01 -0700 (PDT)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 6CCD411E80B1 for ; Mon, 31 Oct 2011 12:18:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ssenthil@cisco.com; l=2502; q=dns/txt; s=iport; t=1320088681; x=1321298281; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=xBtSJKF1pG/o0aiFE6+rpyfzhlxUlXIETLvNsjrTJRU=; b=JGRu6G6XJB9iGrMWLMlWIpKfb8gfqntafVRGuqJ0uO1R/M6GQgE0h0xa SGFAgZb/96RNGc2VX5sIlBo+hKVWzs5Mqr8ghb9t9V4MD99EGMkDLWZA8 DvRAvX1fhT83FMtRKolChjUuyIWmluQNmDQMe4ZGbjb5dYIjatHfMsjr/ U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAFAKzzrk6rRDoH/2dsb2JhbABDqDl8gQWBcgEBAQECAQEBAQ8BKQExCwUNAQgJBQpPBjABAQQBDQUih2AIlVcBnjoEiQIEh1aFIYcXhTaFAIdF
X-IronPort-AV: E=Sophos;i="4.69,433,1315180800"; d="scan'208";a="11479750"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 31 Oct 2011 19:18:01 +0000
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9VJI17d010498; Mon, 31 Oct 2011 19:18:01 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);  Mon, 31 Oct 2011 12:18:00 -0700
Received: from 10.82.240.226 ([10.82.240.226]) by xmb-sjc-236.amer.cisco.com ([128.107.191.121]) with Microsoft Exchange Server HTTP-DAV ;  Mon, 31 Oct 2011 19:18:00 +0000
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Mon, 31 Oct 2011 15:17:58 -0400
From: ssenthil 
To: Cameron Byrne , Benson Schliesser 
Message-ID: 
Thread-Topic: [BEHAVE] CGN Requirements: logging (draft-ietf-behave-lsn-requirements)
Thread-Index: AcyYAcx8bjdhwUcllEaHNJodBt9lzg==
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
X-OriginalArrivalTime: 31 Oct 2011 19:18:00.0876 (UTC) FILETIME=[CE334EC0:01CC9801]
Cc: Olivier Vautrin , "behave@ietf.org" , Dan Wing 
Subject: Re: [BEHAVE] CGN Requirements: logging (draft-ietf-behave-lsn-requirements)
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, 31 Oct 2011 19:18:02 -0000

On 10/29/11 1:20 AM, "Cameron Byrne"  wrote:

> On Fri, Oct 28, 2011 at 8:21 PM, Benson Schliesser  w=
rote:
>>=20
>> On Oct 28, 2011, at 7:44 PM, Olivier Vautrin wrote:
>>=20
>>> What about the "bulk port allocation"? The draft is explaining in detai=
l
>>> the mechanism but do not give any recommendation. I think we should at
>>> least have a "SHOULD" to support the bulk port allocation. It is diffic=
ult
>>> to believe that in the future, service providers we will still log all =
the
>>> sessions on a CGN device.
>>=20
>> I tend to agree with your conclusion. =A0However, if we do per-connection
>> allocation of ports, then there might be benefits to the CGN operator an=
d
>> users. =A0For instance, there might be improved security and more efficien=
t
>> utilization of CGN port resources. =A0Thus, an operator that doesn't care =
about
>> logging might not want to use bulk port allocation.
>>=20
>> My opinion is that if we say that a CGN "SHOULD" do bulk port allocation=
,
>> then we should also say that it "MAY" do per-connection port allocation
>> (based on the rationale I just described). =A0Thoughts on this?
>>=20
>=20
> I would rather not see any recommendation here.  SHOULD is in fact a
> very strong word in the IETF.  If something must be said, then we
> should say both SHOULD be implemented for the operator to choose.
>=20
> I have been operating a CGN probably longer than there has been the
> term CGN without bulk port and i see no compelling reason to change.
> In fact, we had an operational issue with a new CGN implementation
> that was reserving ports and had a substantial issue load-balancing
> bulk connections over CPU cores when bittorrent clients would request
> thousands of connections from a single internal IP... resulting in bad
> chunking effects.

I agree that the recommendation should not be towards one mechanism over th=
e
other. I have customers who use per-connection logging  who never
complained. It should be upto the network operator to choose what is best
for their deployment.

Senthil

>=20
> Cameron
>=20
>=20
>> Cheers,
>> -Benson
>>=20
>> _______________________________________________
>> Behave mailing list
>> Behave@ietf.org
>> https://www.ietf.org/mailman/listinfo/behave
>>=20
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave


From brian.e.carpenter@gmail.com  Mon Oct 31 13:23: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 CBB9411E81D7 for ; Mon, 31 Oct 2011 13:23:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.52
X-Spam-Level: 
X-Spam-Status: No, score=-103.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uh0FH6i6jR1q for ; Mon, 31 Oct 2011 13:23:01 -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 A622B11E81CE for ; Mon, 31 Oct 2011 13:23:00 -0700 (PDT)
Received: by wwi36 with SMTP id 36so1360757wwi.13 for ; Mon, 31 Oct 2011 13:22:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=wt59+8TCsu2EQ8aAjNyjR8ZX/Fs8DTY7X93GsTZLS5w=; b=ufR6R+aGYo745Mjv4guHHWsO4kd23Gn4EIeHnYMVLwbrssONFWIYk9k1RJuxnbKD/6 B8SbIjsV1ci852dcRnm3xhx44pswFj7Ll/qbK89ExrgMqr3rIseOyuPMhi6jMIiFof4C noYmX6uc7n+FXBZfD0yfS1Nwkwl6rborfiGBY=
Received: by 10.227.204.204 with SMTP id fn12mr19652469wbb.21.1320092574053; Mon, 31 Oct 2011 13:22:54 -0700 (PDT)
Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id es5sm34460957wbb.11.2011.10.31.13.22.50 (version=SSLv3 cipher=OTHER); Mon, 31 Oct 2011 13:22:53 -0700 (PDT)
Message-ID: <4EAF0384.1050002@gmail.com>
Date: Tue, 01 Nov 2011 09:22:28 +1300
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Prashanth Patil 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: behave@ietf.org
Subject: Re: [BEHAVE] I-D Action: draft-wing-behave-dhcpv6-reconfigure-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, 31 Oct 2011 20:23:01 -0000

I don't get it. If a host is dual stacked it can be configured with
any DNS server, as long as it is not a DNS64. If you can have a
DNS64 directly visible, and a v4-only DNS server directly visible,
you are on a dual stack network, so you can also have a dual stack
DNS server directly visible.

Regards
   Brian Carpenter

On 2011-11-01 05:05, Prashanth Patil wrote:
> Hi Brian,=20
> The idea behind the proposal is to provision a means by which traffic i=
s
> sent using IPv4 and not through the IPv6/IPv4 translator. The advantage=

> being that if NAT44 and NAT64 are deployed on the same network, it is
> preferable to use NAT44 over NAT64 because of scale, performance and
> application incompatibility issues (e.g., FTP) [RFC6384].
> A "normal" DNS server does not have DNS64 capability. The IPv4-mapped
> address for this "normal" server ensures that it can be reached only by=

> IPv4=C5=A1. So if a host is IPv4-only, it will send a DNS query to the =
"normal"
> server just to get the A records. If the host is dual-stack it will als=
o
> send a DNS query to the "normal" server to get both A and AAAA records.=
 If
> the destination address is an IPv4 address,  dual-stack host just gets =
A
> records but not synthesized AAAA records. So this technique will ensure=
 that
> IPv4 is preferred over the IPv6/IPv4 translator prefix and also gives n=
ative
> IPv6 higher precedence than IPv4.
> If the host happens to be IPv6 only, then it cannot reach the "normal"
> server because it has IPv4-mapped prefix as explained previously. So IP=
v6
> only host can only reach DNS64 server. So this host will send the DNS q=
uery
> to DNS64 to get AAAA records. Based on the destination address the host=
 will
> get IPv4-embedded IPv6 address or just the global IPv6 address.
>=20
> =C5=A1Note: From RFC 6052
> =C2=B3When presented with the IPv4-mapped prefix, current versions of W=
indows and
> Mac OS generate IPv4 packets, but will not send IPv6 packets.=C2=B2
>=20
> -Prashanth=20
>=20
> On 22/10/11 6:20 AM, Brian E Carpenter wrote:
>> I have a basic question. Why does this draft define a 'normal'
>> DNS server as one having an IPv4-mapped IPv6 address?
>>
>> That seems like a completely *abnormal* DNS server for a dual
>> stack host. A dual stack host should normally have a DNS server
>> with a regular IPv6 address that will return both A and AAAA
>> records if they exist. Normally the server will be dual stacked
>> anyway, and will return exactly the same response whether the
>> query arrives via v4 or v6.
>>
>> A DNS server which only has an IPv4 address will also return
>> A and AAAA records if they exist, so there is absolutely no
>> difference as far as the dual stack host is concerned anyway.
>> So what is the point in using the IPv4-mapped address?
>>
>> Regards=20
>>     Brian=20
>>
>> On 2011-10-18 11:17, internet-drafts@ietf.org wrote:
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.=20
>>>
>>>     Title           : DHCPv6 Dynamic Re-Configuration
>>>     Author(s)       : Dan Wing
>>>                            Tirumaleswar Reddy
>>>                            Prashanth Patil
>>>     Filename        : draft-wing-behave-dhcpv6-reconfigure-00.txt
>>>     Pages           : 10
>>>     Date            : 2011-10-17
>>>
>>>     Some networks are expected to support IPv4-only, dual-stack, and
>>>     IPV6-only hosts at the same time.  This makes prioritizing the DN=
S
>>>     servers for hosts tricky due to a heterogeneous mix of protocol
>>>     stacks causing optimal behavior to occur only when the host stack=
 re-
>>>     initializes.  The networks infrastructure is usually well equippe=
d to
>>>     be aware of single/dual-stack nature of hosts.  This specificatio=
n
>>>     extends DHCPv6 so that the DHCPv6 Relay Agent can dynamically
>>>     influence the priority of DNS servers provided to the host, so th=
at
>>>     the host can use the optimal DNS server for resolution.
>>>
>>>
>>> A URL for this Internet-Draft is:
>>> http://www.ietf.org/internet-drafts/draft-wing-behave-dhcpv6-reconfig=
ure-00.t
>>> xt=20
>>>
>>> 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-wing-behave-dhcpv6-reconfigu=
re-00.tx
>>> t=20
>>> _______________________________________________
>>> I-D-Announce mailing list
>>> I-D-Announce@ietf.org
>>> https://www.ietf.org/mailman/listinfo/i-d-announce
>>> Internet-Draft directories: http://www.ietf.org/shadow.html
>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>
>> _______________________________________________
>> Behave mailing list
>> Behave@ietf.org=20
>> https://www.ietf.org/mailman/listinfo/behave
>=20
>=20
>=20


From ovautrin@juniper.net  Mon Oct 31 22:33: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 899F821F8E61 for ; Mon, 31 Oct 2011 22:33:32 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4PCKaB1Jo9XI for ; Mon, 31 Oct 2011 22:33:32 -0700 (PDT)
Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id DBFC021F8E5F for ; Mon, 31 Oct 2011 22:33:31 -0700 (PDT)
Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP;  Mon, 31 Oct 2011 22:33:31 PDT
Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Mon, 31 Oct 2011 22:32:54 -0700
From: Olivier Vautrin 
To: Benson Schliesser 
Date: Mon, 31 Oct 2011 22:32:52 -0700
Thread-Topic: [BEHAVE] CGN Requirements: logging (draft-ietf-behave-lsn-requirements)
Thread-Index: AcyYV7P69e96dZr5S4+PuzLGA6AkBg==
Message-ID: 
In-Reply-To: <412F66EB-9ADF-448D-9324-582F2D0B9AFD@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.13.0.110805
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "behave@ietf.org" , Dan Wing 
Subject: Re: [BEHAVE] CGN Requirements: logging (draft-ietf-behave-lsn-requirements)
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, 01 Nov 2011 05:33:32 -0000

I agree. What about "SHOULD" support per-connection if logging is not
needed. "SHOULD" support bulk port allocation if Logging is needed.

Cheers,
Olivier

On 10/28/11 8:21 PM, "Benson Schliesser"  wrote:

>
>On Oct 28, 2011, at 7:44 PM, Olivier Vautrin wrote:
>
>> What about the "bulk port allocation"? The draft is explaining in detail
>> the mechanism but do not give any recommendation. I think we should at
>> least have a "SHOULD" to support the bulk port allocation. It is
>>difficult
>> to believe that in the future, service providers we will still log all
>>the
>> sessions on a CGN device.
>
>I tend to agree with your conclusion.  However, if we do per-connection
>allocation of ports, then there might be benefits to the CGN operator and
>users.  For instance, there might be improved security and more efficient
>utilization of CGN port resources.  Thus, an operator that doesn't care
>about logging might not want to use bulk port allocation.
>
>My opinion is that if we say that a CGN "SHOULD" do bulk port allocation,
>then we should also say that it "MAY" do per-connection port allocation
>(based on the rationale I just described).  Thoughts on this?
>
>Cheers,
>-Benson
>