From ietfdbh@comcast.net Wed Aug 3 15:51:11 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B705411E80B2 for ; Wed, 3 Aug 2011 15:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qNRHaPNAjfNs for ; Wed, 3 Aug 2011 15:51:11 -0700 (PDT) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF3011E809B for ; Wed, 3 Aug 2011 15:51:11 -0700 (PDT) Received: from omta16.emeryville.ca.mail.comcast.net ([76.96.30.72]) by qmta09.emeryville.ca.mail.comcast.net with comcast id Fyj61h00D1ZMdJ4A9yrLaF; Wed, 03 Aug 2011 22:51:20 +0000 Received: from davidPC ([67.189.235.106]) by omta16.emeryville.ca.mail.comcast.net with comcast id Fyoj1h00z2JQnJT8cyorFl; Wed, 03 Aug 2011 22:49:00 +0000 From: "David Harrington" To: , , Date: Wed, 3 Aug 2011 18:50:57 -0400 Message-ID: <7AA26F5380BF4CFCBAAA20D91C13FD65@davidPC> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.1.7601.17609 Thread-index: AcxSL86/Ib1EjQ75T7STyzdBpariUw== Subject: [BEHAVE] AD review of draft-ietf-behave-v4v6-bih-05 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, 03 Aug 2011 22:51:11 -0000 Hi, Below is the AD review of draft-ietf-behave-v4v6-bih-05. Most are editorial comments. Some are RFC2119-related. Some are simply questions I would like answered, and the answer might be best in the document so other readers know the answers as well. === AD review of draft-ietf-behave-v4v6-bih-05 The abstract or section 1.1 should explain WHY a successor is needed. 2.1 refers to Appendix B; there is no appendix B. Typically appendices are used for non-normative content, but this appendix lists functions that MUST be intercepted (according to 2.1). This would probably be better placed in the main part of the document. 2.1 says the APIs MUST be intercepted; the Appendix says they SHOULD be intercepted. Which is it? 2.2 says "Protocol translation SHOULD NOT be performed for IPv4 packets sent to the IPv4 address range used by local synthesis and for which a mapping table entry does not exist. The implementation SHOULD attempt to route such packets via IPv4 interfaces instead." Why should and not MUST? Is should, what ar ethe valid exceptions to the recommended practice? 2.3 "returns a proper answer" => returns an answer 2.3 RECOMMENDS the socket API layer option. When is it appropriate to use the other option? in 2.3 "In either implementation option, if there is a real IPv4 address available, the ENR SHOULD NOT synthesize IPv4 addresses. By default an ENR implementation MUST NOT synthesize IPv4 addresses when real IPv4 addresses exist." Why only should not? What is the valid exception to a MUST NOT? (is this discussed elsewhere in the document?) 2.3.1 what is a martian address? can you give a reference for this phrase? overuse of "essentially"; this is typically not needed where it is used. "essentially the same" => similar in 2.3.2 "The ENR can support DNSSEC as any resolver on a host." I don't understand this sentence, especially "as any resolver". in 2.3.2, the main resolver MUST use the CD bit; what are the operational implications of requiring this? in 2.3.2, are DNS questions the same as DNS queries? in 2.3.2, I don't like the wording in "In order to properly support DNSSEC, the ENR SHOULD be implemented at the socket API level. If the socket API level implementation is not possible, DNSSEC support SHOULD be provided by other means." Properly support is not a technical phrase; do you mean to be compliant to dnssec? Do you mean to secure the DNS environment? If the socket API is not implemented, why isn't DNSSEC support MUST be provided by other means? If an implementation does not provide dnssec support by other means, then what happens to the security properties of the trusted environment? would not doing this create a vulnerability? in 4.4, why is the primary address space /30, whereas the other address spaces are /20s? in 7, "The security considerations of BIH mostly relies on that of [RFC6146]." Do you mean "The security considerations found in RFC6146 apply, with the following additional considerations specific to BIH"? in 7, it says "the differences are due to ..." - the differences between what and what? Do you mean between 6146 and this document? If so, simply discuss the considerations for this document. Doing this as a comparison to the other document is a bit confusing, and would really require the reader to have both documents open and to do a diff to understand your text. s/In the socket-layer implementation approach, the differences are due to the address translation occurring at the API and not in the network layer. That is, since the mechanism/When the implementation/ in 7, "So BIH should employ the same sort of protection techniques as NAT64 [RFC6146] does." I am not sure which protections you refer to here. I think it would be better to point to specific relevant solutions in 6146. The only mention of denial of service in 6146 is in section 1.2.3. Is that the protection you mean? in 9, s/The author thanks/The authors thank/ David Harrington Director, IETF Transport Area ietfdbh@comcast.net (preferred for ietf) dbharrington@huaweisymantec.com +1 603 828 1401 (cell) From ietfdbh@comcast.net Wed Aug 3 17:12:55 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B413C21F855F for ; Wed, 3 Aug 2011 17:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87e9r5vcvMCa for ; Wed, 3 Aug 2011 17:12:55 -0700 (PDT) Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by ietfa.amsl.com (Postfix) with ESMTP id 489F721F854F for ; Wed, 3 Aug 2011 17:12:55 -0700 (PDT) Received: from omta23.emeryville.ca.mail.comcast.net ([76.96.30.90]) by qmta05.emeryville.ca.mail.comcast.net with comcast id Fzzp1h0021wfjNsA50D5Ey; Thu, 04 Aug 2011 00:13:05 +0000 Received: from davidPC ([67.189.235.106]) by omta23.emeryville.ca.mail.comcast.net with comcast id G0Ch1h0152JQnJT8j0CnAz; Thu, 04 Aug 2011 00:12:52 +0000 From: "David Harrington" To: Date: Wed, 3 Aug 2011 20:12:47 -0400 Message-ID: <285AA91F41624C6B963A45FECC73F56E@davidPC> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.1.7601.17609 Thread-index: AcxSOz1+np/vF0xnTkWaM1paeuvypw== Subject: [BEHAVE] Closing the behave WG 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, 04 Aug 2011 00:12:55 -0000 Hi, As Responsible Area Director, I have received a request from the behave WG chairs to consider closing the behave working group, rather than rechartering to do additional work. The chairs and the IESG agree that closing the WG after completing the current milestones would be a good thing, to signal that the chartered behave work items supporting transition to IPv6 have been completed. During ietf81, the chairs discussed with the working group the possible closing of the working group. Additional work, such as those drafts identified in the chairs' slides, can be proposed for completion in existing working groups (or in new working groups). None of this would be automatic; the proponents would need to convince an existing WG to adopt their draft, or would need to convince the IESG a new working group is justified using the normal methods for requesting a new working group. The behave chairs have agreed to serve as technical advisors to working groups that take on such work, if needed. In my opinion, the sense of the room was to support this closure. As Responsible area director, I plan to make a decision on WG closure in the next few weeks, and would like to give the WG mailing list members a chance to provide feedback on this proposed closure. Please send substantive comments to the behave@ietf.org mailing list by 2011-08-15, with the above Subject line. David Harrington Director, IETF Transport Area ietfdbh@comcast.net (preferred for ietf) dbharrington@huaweisymantec.com +1 603 828 1401 (cell) From rpenno@juniper.net Thu Aug 4 01:00:19 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26E8321F8B6A for ; Thu, 4 Aug 2011 01:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.467 X-Spam-Level: X-Spam-Status: No, score=-6.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lr8ApZx+bgwf for ; Thu, 4 Aug 2011 01:00:18 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id D0EFB21F874A for ; Thu, 4 Aug 2011 01:00:17 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKTjpRjWsYfzdVEoj7TJBSvyYbeitQNH+p@postini.com; Thu, 04 Aug 2011 01:00:32 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 4 Aug 2011 00:58:24 -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; Thu, 4 Aug 2011 03:58:23 -0400 From: Reinaldo Penno To: David Harrington , "behave@ietf.org" Date: Thu, 4 Aug 2011 03:58:21 -0400 Thread-Topic: [BEHAVE] Closing the behave WG Thread-Index: AcxSOz1+np/vF0xnTkWaM1paeuvypwAQQmoO Message-ID: In-Reply-To: <285AA91F41624C6B963A45FECC73F56E@davidPC> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.9.0.110114 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] Closing the behave WG 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, 04 Aug 2011 08:00:19 -0000 On 8/3/11 5:12 PM, "David Harrington" wrote: > Hi, >=20 > As Responsible Area Director, I have received a request from the > behave WG chairs to consider closing the behave working group, rather > than rechartering to do additional work. >=20 I vote for rechartering. There is very important work to be done in this area, specially given the CGN traction in the market. I would like to see a= t least the following drafts published. http://tools.ietf.org/html/draft-sivakumar-behave-nat-logging-02 https://tools.ietf.org/html/draft-penno-behave-rfc4787-5382-5508-bis-00 > The chairs and the IESG agree that closing the WG after completing the > current milestones would be a good thing, to signal that the chartered > behave work items supporting transition to IPv6 have been completed. I understand BEHAVE have been around for a while and if it is taking a lot of the chairs' time maybe we could consider changing the chairs for the nex= t rechartering.=20 >=20 > During ietf81, the chairs discussed with the working group the > possible closing of the working group. Additional work, such as those > drafts identified in the chairs' slides, can be proposed for > completion in existing working groups (or in new working groups). > None > of this would be automatic; the proponents would need to convince an > existing WG to adopt their draft, or would need to convince the IESG a > new working group is justified using the normal methods for requesting > a new working group. The behave chairs have agreed to serve as > technical advisors to working groups that take on such work, if > needed.=20 >=20 > In my opinion, the sense of the room was to support this closure. >=20 > As Responsible area director, I plan to make a decision on WG closure > in the next few weeks, and would like to give the WG mailing list > members a chance to provide feedback on this proposed closure. Please > send substantive comments to the > behave@ietf.org mailing list by 2011-08-15, with the above Subject > line. >=20 > David Harrington > Director, IETF Transport Area > ietfdbh@comcast.net (preferred for ietf) > dbharrington@huaweisymantec.com > +1 603 828 1401 (cell) >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From xuxiaohu@huawei.com Thu Aug 4 02:48:00 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9A9621F88B7 for ; Thu, 4 Aug 2011 02:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.268 X-Spam-Level: X-Spam-Status: No, score=0.268 tagged_above=-999 required=5 tests=[AWL=2.325, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HC9ggll8FZtJ for ; Thu, 4 Aug 2011 02:48:00 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id DCFD921F8841 for ; Thu, 4 Aug 2011 02:47:59 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPE0024DDUFQH@szxga05-in.huawei.com> for behave@ietf.org; Thu, 04 Aug 2011 17:47:03 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPE00KCHDTKV8@szxga05-in.huawei.com> for behave@ietf.org; Thu, 04 Aug 2011 17:47:03 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml203-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACX29842; Thu, 04 Aug 2011 17:47:02 +0800 (CST) Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 04 Aug 2011 17:46:56 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.69]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.01.0270.001; Thu, 04 Aug 2011 17:47:01 +0800 Date: Thu, 04 Aug 2011 09:47:02 +0000 From: Xuxiaohu In-reply-to: X-Originating-IP: [10.110.98.53] To: Reinaldo Penno , David Harrington , "behave@ietf.org" Message-id: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE6FF100@szxeml525-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [BEHAVE] Closing the behave WG Thread-index: AcxSOz1+np/vF0xnTkWaM1paeuvypwAQQmoOAAMEaJA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <285AA91F41624C6B963A45FECC73F56E@davidPC> Subject: Re: [BEHAVE] Closing the behave WG 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, 04 Aug 2011 09:48:01 -0000 SSdtIGFsc28gaW4gZmF2b3Igb2YgcmVjaGFydGVyaW5nIGR1ZSB0byB0aGUgc2FtZSByZWFzb24g bWVudGlvbmVkIGJ5IFJlaW5hbGRvLCB0aGF0IGlzLCB0aGVyZSBpcyBzdGlsbCBhIGxvdCBvZiB2 ZXJ5IGltcG9ydGFudCB3b3JrIHRvIGJlIGRvbmUgaW4gdGhpcyBhcmVhLiANCg0KU2luY2UgQ0dO cyBhcmUgdXN1YWxseSBkZXBsb3llZCBpbiBJU1AgbmV0d29ya3Mgb3IgbGFyZ2UgZW50ZXJwcmlz ZSBuZXR3b3JrcywgcmF0aGVyIHRoYW4gaW4gaG9tZSBuZXR3b3JrcywgYW5kIHRoZXNlIGRldmlj ZXMgdXN1YWxseSBjYXJyeSBhIGxhcmdlIHZvbHVtZSBvZiB0cmFmZmljIGFuZCB1c2VycywgaGln aCBhdmFpbGFiaWxpdHkgYW5kIGxvYWQtYmFsYW5jaW5nIGFyZSBtdWNoIGRlc2lyYWJsZSBmZWF0 dXJlcyBmb3IgbW9zdCBDR04gb3BlcmF0b3JzLiBBbHRob3VnaCBwcm9wcmlldGFyeSBzb2x1dGlv bnMgYXJlIGF2YWlsYWJsZSB0byBzb21lIGV4dGVudCwgdmVuZG9yIGxvY2staW4gYW5kIHNpbXVs dGFuZW91cyBmYWlsdXJlIGR1ZSB0byB0aGUgc2FtZSBidWcgYXJlIHR3byBzaWRlLWVmZmVjdHMg d2l0aCBzdWNoIHByb3ByaWV0YXJ5IHNvbHV0aW9ucywgd2hpY2ggYXJlIG5vdCBtdWNoIGFjY2Vw dGFibGUgdG8gc29tZSBvcGVyYXRvcnMuIEhlbmNlIEkgZG8gc3VnZ2VzdCB0aGUgV0cgY291bGQg cmVjb25zaWRlciB0aGVzZSB0d28gaW1wb3J0YW50IGZlYXR1cmVzIGZvciBDR05zIGlmL3doZW4g cmVjaGFydGVyaW5nLg0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0KPiAtLS0tLdPKvP7Urbz+ LS0tLS0NCj4gt6K8/sjLOiBiZWhhdmUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmJlaGF2ZS1i b3VuY2VzQGlldGYub3JnXSC0+rHtDQo+IFJlaW5hbGRvIFBlbm5vDQo+ILeiy83KsbzkOiAyMDEx xOo41MI0yNUgMTU6NTgNCj4gytW8/sjLOiBEYXZpZCBIYXJyaW5ndG9uOyBiZWhhdmVAaWV0Zi5v cmcNCj4g1vfM4jogUmU6IFtCRUhBVkVdIENsb3NpbmcgdGhlIGJlaGF2ZSBXRw0KPiANCj4gDQo+ IA0KPiANCj4gT24gOC8zLzExIDU6MTIgUE0sICJEYXZpZCBIYXJyaW5ndG9uIiA8aWV0ZmRiaEBj b21jYXN0Lm5ldD4gd3JvdGU6DQo+IA0KPiA+IEhpLA0KPiA+DQo+ID4gQXMgUmVzcG9uc2libGUg QXJlYSBEaXJlY3RvciwgSSBoYXZlIHJlY2VpdmVkIGEgcmVxdWVzdCBmcm9tIHRoZQ0KPiA+IGJl aGF2ZSBXRyBjaGFpcnMgdG8gY29uc2lkZXIgY2xvc2luZyB0aGUgYmVoYXZlIHdvcmtpbmcgZ3Jv dXAsIHJhdGhlcg0KPiA+IHRoYW4gcmVjaGFydGVyaW5nIHRvIGRvIGFkZGl0aW9uYWwgd29yay4N Cj4gPg0KPiANCj4gSSB2b3RlIGZvciByZWNoYXJ0ZXJpbmcuIFRoZXJlIGlzIHZlcnkgaW1wb3J0 YW50IHdvcmsgdG8gYmUgZG9uZSBpbiB0aGlzDQo+IGFyZWEsIHNwZWNpYWxseSBnaXZlbiB0aGUg Q0dOIHRyYWN0aW9uIGluIHRoZSBtYXJrZXQuIEkgd291bGQgbGlrZSB0byBzZWUgYXQNCj4gbGVh c3QgdGhlIGZvbGxvd2luZyBkcmFmdHMgcHVibGlzaGVkLg0KPiANCj4gaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtc2l2YWt1bWFyLWJlaGF2ZS1uYXQtbG9nZ2luZy0wMg0KPiBodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcGVubm8tYmVoYXZlLXJmYzQ3ODctNTM4Mi01 NTA4LWJpcy0wMA0KPiANCj4gPiBUaGUgY2hhaXJzIGFuZCB0aGUgSUVTRyBhZ3JlZSB0aGF0IGNs b3NpbmcgdGhlIFdHIGFmdGVyIGNvbXBsZXRpbmcgdGhlDQo+ID4gY3VycmVudCBtaWxlc3RvbmVz IHdvdWxkIGJlIGEgZ29vZCB0aGluZywgdG8gc2lnbmFsIHRoYXQgdGhlIGNoYXJ0ZXJlZA0KPiA+ IGJlaGF2ZSB3b3JrIGl0ZW1zIHN1cHBvcnRpbmcgdHJhbnNpdGlvbiB0byBJUHY2IGhhdmUgYmVl biBjb21wbGV0ZWQuDQo+IA0KPiBJIHVuZGVyc3RhbmQgQkVIQVZFIGhhdmUgYmVlbiBhcm91bmQg Zm9yIGEgd2hpbGUgYW5kIGlmIGl0IGlzIHRha2luZyBhIGxvdA0KPiBvZiB0aGUgY2hhaXJzJyB0 aW1lIG1heWJlIHdlIGNvdWxkIGNvbnNpZGVyIGNoYW5naW5nIHRoZSBjaGFpcnMgZm9yIHRoZSBu ZXh0DQo+IHJlY2hhcnRlcmluZy4NCj4gDQo+ID4NCj4gPiBEdXJpbmcgaWV0ZjgxLCB0aGUgY2hh aXJzIGRpc2N1c3NlZCB3aXRoIHRoZSB3b3JraW5nIGdyb3VwIHRoZQ0KPiA+IHBvc3NpYmxlIGNs b3Npbmcgb2YgdGhlIHdvcmtpbmcgZ3JvdXAuIEFkZGl0aW9uYWwgd29yaywgc3VjaCBhcyB0aG9z ZQ0KPiA+IGRyYWZ0cyBpZGVudGlmaWVkIGluIHRoZSBjaGFpcnMnIHNsaWRlcywgY2FuIGJlIHBy b3Bvc2VkIGZvcg0KPiA+IGNvbXBsZXRpb24gaW4gZXhpc3Rpbmcgd29ya2luZyBncm91cHMgKG9y IGluIG5ldyB3b3JraW5nIGdyb3VwcykuDQo+ID4gTm9uZQ0KPiA+IG9mIHRoaXMgd291bGQgYmUg YXV0b21hdGljOyB0aGUgcHJvcG9uZW50cyB3b3VsZCBuZWVkIHRvIGNvbnZpbmNlIGFuDQo+ID4g ZXhpc3RpbmcgV0cgdG8gYWRvcHQgdGhlaXIgZHJhZnQsIG9yIHdvdWxkIG5lZWQgdG8gY29udmlu Y2UgdGhlIElFU0cgYQ0KPiA+IG5ldyB3b3JraW5nIGdyb3VwIGlzIGp1c3RpZmllZCB1c2luZyB0 aGUgbm9ybWFsIG1ldGhvZHMgZm9yIHJlcXVlc3RpbmcNCj4gPiBhIG5ldyB3b3JraW5nIGdyb3Vw LiBUaGUgYmVoYXZlIGNoYWlycyBoYXZlIGFncmVlZCB0byBzZXJ2ZSBhcw0KPiA+IHRlY2huaWNh bCBhZHZpc29ycyB0byB3b3JraW5nIGdyb3VwcyB0aGF0IHRha2Ugb24gc3VjaCB3b3JrLCBpZg0K PiA+IG5lZWRlZC4NCj4gPg0KPiA+IEluIG15IG9waW5pb24sIHRoZSBzZW5zZSBvZiB0aGUgcm9v bSB3YXMgdG8gc3VwcG9ydCB0aGlzIGNsb3N1cmUuDQo+ID4NCj4gPiBBcyBSZXNwb25zaWJsZSBh cmVhIGRpcmVjdG9yLCBJIHBsYW4gdG8gbWFrZSBhIGRlY2lzaW9uIG9uIFdHIGNsb3N1cmUNCj4g PiBpbiB0aGUgbmV4dCBmZXcgd2Vla3MsIGFuZCB3b3VsZCBsaWtlIHRvIGdpdmUgdGhlIFdHIG1h aWxpbmcgbGlzdA0KPiA+IG1lbWJlcnMgYSBjaGFuY2UgdG8gcHJvdmlkZSBmZWVkYmFjayBvbiB0 aGlzIHByb3Bvc2VkIGNsb3N1cmUuIFBsZWFzZQ0KPiA+IHNlbmQgc3Vic3RhbnRpdmUgY29tbWVu dHMgdG8gdGhlDQo+ID4gYmVoYXZlQGlldGYub3JnIG1haWxpbmcgbGlzdCBieSAyMDExLTA4LTE1 LCB3aXRoIHRoZSBhYm92ZSBTdWJqZWN0DQo+ID4gbGluZS4NCj4gPg0KPiA+IERhdmlkIEhhcnJp bmd0b24NCj4gPiBEaXJlY3RvciwgSUVURiBUcmFuc3BvcnQgQXJlYQ0KPiA+IGlldGZkYmhAY29t Y2FzdC5uZXQgKHByZWZlcnJlZCBmb3IgaWV0ZikNCj4gPiBkYmhhcnJpbmd0b25AaHVhd2Vpc3lt YW50ZWMuY29tDQo+ID4gKzEgNjAzIDgyOCAxNDAxIChjZWxsKQ0KPiA+DQo+ID4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBCZWhhdmUgbWFpbGlu ZyBsaXN0DQo+ID4gQmVoYXZlQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9iZWhhdmUNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IEJlaGF2ZSBtYWlsaW5nIGxpc3QNCj4gQmVoYXZlQGlldGYu b3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYmVoYXZlDQo= From simon.perreault@viagenie.ca Thu Aug 4 05:58:10 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F58621F8AFA for ; Thu, 4 Aug 2011 05:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8OtHiyvU7I5H for ; Thu, 4 Aug 2011 05:58:09 -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 D286321F8AD8 for ; Thu, 4 Aug 2011 05:58:09 -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 4173B21CB6 for ; Thu, 4 Aug 2011 08:58:24 -0400 (EDT) Message-ID: <4E3A976F.5080404@viagenie.ca> Date: Thu, 04 Aug 2011 08:58:23 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: behave@ietf.org References: <285AA91F41624C6B963A45FECC73F56E@davidPC> In-Reply-To: <285AA91F41624C6B963A45FECC73F56E@davidPC> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] Closing the behave WG 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, 04 Aug 2011 12:58:10 -0000 On 2011-08-03 20:12, David Harrington wrote: > In my opinion, the sense of the room was to support this closure. I disagree. Several people went to the mic to talk about additional work that needs to be done. In addition, I think many authors of drafts that were on the "potential additional work" slides were not at this meeting. Personally, I've stated at the mic that the CGN logging issue is very important to many people right now and that there is a need for a standard solution. There are at least two drafts currently trying to address this issue. We have the right people in behave right now to address this problem. Moving this work to another working group would be detrimental. 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 sob@academ.com Thu Aug 4 06:47:09 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE65521F8B0F for ; Thu, 4 Aug 2011 06:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NsMm9Pli9tJ7 for ; Thu, 4 Aug 2011 06:47:09 -0700 (PDT) Received: from bdr.academ.com (unknown [IPv6:2001:418:6802::76]) by ietfa.amsl.com (Postfix) with ESMTP id 052F621F852E for ; Thu, 4 Aug 2011 06:47:08 -0700 (PDT) Received: from [10.63.84.72] (gw1.cox.com [24.248.74.254]) (authenticated bits=0) by bdr.academ.com (8.14.4/8.14.4) with ESMTP id p74DlKPS021693 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 4 Aug 2011 08:47:21 -0500 (CDT) (envelope-from sob@academ.com) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Stan Barber In-Reply-To: <4E3A976F.5080404@viagenie.ca> Date: Thu, 4 Aug 2011 09:47:20 -0400 Content-Transfer-Encoding: 7bit Message-Id: <7A54A1A7-74D5-4549-813E-E62EFBD1A310@academ.com> References: <285AA91F41624C6B963A45FECC73F56E@davidPC> <4E3A976F.5080404@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1244.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (bdr.academ.com [198.137.249.76]); Thu, 04 Aug 2011 08:47:22 -0500 (CDT) Cc: behave@ietf.org Subject: Re: [BEHAVE] Closing the behave WG 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, 04 Aug 2011 13:47:09 -0000 I also agree there is much work still on the table for this group. If not done in BEHAVE, is there another place this work could be done? On Aug 4, 2011, at 8:58 AM, Simon Perreault wrote: > On 2011-08-03 20:12, David Harrington wrote: >> In my opinion, the sense of the room was to support this closure. > > I disagree. Several people went to the mic to talk about additional work > that needs to be done. In addition, I think many authors of drafts that > were on the "potential additional work" slides were not at this meeting. > > Personally, I've stated at the mic that the CGN logging issue is very > important to many people right now and that there is a need for a > standard solution. There are at least two drafts currently trying to > address this issue. We have the right people in behave right now to > address this problem. Moving this work to another working group would be > detrimental. > > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From cb.list6@gmail.com Thu Aug 4 08:12: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 0AB2121F8B82 for ; Thu, 4 Aug 2011 08:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.425 X-Spam-Level: X-Spam-Status: No, score=-3.425 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4NfCQTHuV+7 for ; Thu, 4 Aug 2011 08:12:00 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 36DEB21F8B76 for ; Thu, 4 Aug 2011 08:12:00 -0700 (PDT) Received: by wyg8 with SMTP id 8so563850wyg.31 for ; Thu, 04 Aug 2011 08:12:13 -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; bh=pIEC+cdxwD2TMnkaxPwkWt8RLyYwZlbwgkmHArIR4aQ=; b=kUUINJQU8lP+ffvU7CWEpMLodWFH73TODtSazxKzId15CXWjx68SyoP6Z/cG7T/6rW hws8g4x6wHbaBznMA5jRjd6vwieuUi1c91lyZJiADraslqcugJrMfw6hXMa0+VnGPR5d Oy/TK8CJSpohJ9DAMrWERbmilzJ2KN9Wjk9es= MIME-Version: 1.0 Received: by 10.216.66.149 with SMTP id h21mr803560wed.103.1312470733591; Thu, 04 Aug 2011 08:12:13 -0700 (PDT) Received: by 10.216.177.213 with HTTP; Thu, 4 Aug 2011 08:12:13 -0700 (PDT) Received: by 10.216.177.213 with HTTP; Thu, 4 Aug 2011 08:12:13 -0700 (PDT) In-Reply-To: <285AA91F41624C6B963A45FECC73F56E@davidPC> References: <285AA91F41624C6B963A45FECC73F56E@davidPC> Date: Thu, 4 Aug 2011 08:12:13 -0700 Message-ID: From: Cameron Byrne To: David Harrington Content-Type: multipart/alternative; boundary=000e0ce0d8acda93b504a9af67d7 Cc: behave@ietf.org Subject: Re: [BEHAVE] Closing the behave WG 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, 04 Aug 2011 15:12:01 -0000 --000e0ce0d8acda93b504a9af67d7 Content-Type: text/plain; charset=ISO-8859-1 I disagree that it should be closed and suggest that the nat464 (as described in pnat, 4v6, and bih) be properly named nat464, generalized, and brought into this group, softwire is not the right place. It is a shame that nat464 has such a bad name that the concept has to be veiled in various other specs Cb --000e0ce0d8acda93b504a9af67d7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I disagree that it should be closed and suggest that the nat464 (as desc= ribed in pnat, 4v6, and bih) be properly named nat464, generalized, and bro= ught into this group, softwire is not the right place. It is a shame that n= at464 has such a bad name that the concept has to be veiled in various othe= r specs

Cb

--000e0ce0d8acda93b504a9af67d7-- From teemu.savolainen@nokia.com Thu Aug 4 11:32: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 B787B21F8557 for ; Thu, 4 Aug 2011 11:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncxZC7xcAnie for ; Thu, 4 Aug 2011 11:32:51 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 7F27F21F8551 for ; Thu, 4 Aug 2011 11:32:51 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p74IWo9g030074 for ; Thu, 4 Aug 2011 21:33:05 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 4 Aug 2011 21:31:57 +0300 Received: from 008-AM1MMR1-003.mgdnok.nokia.com (65.54.30.58) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 4 Aug 2011 20:31:56 +0200 Received: from 008-AM1MPN1-037.mgdnok.nokia.com ([169.254.7.163]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.01.0323.002; Thu, 4 Aug 2011 20:31:53 +0200 From: To: Thread-Topic: Happy Eyeballs and DNS64 not sending synthetic AAAA RRs Thread-Index: AcxS1D8ayyrhOKVBTGawrQrX46lAgA== Date: Thu, 4 Aug 2011 18:31:53 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962A6F825@008-AM1MPN1-037.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Company Confidential;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: /l7IPXixAhc7RTUH/zCwps6GcP7OK+zjsfoTSGofSciLGCbOaU6/9+UwMhWRtore1qsp7DBaXDcNlEa6QQeYbDkRSdrdifvAr0QP4DaKpIma8YdLFNQJp2joa5K8O8/h9l1S3hwdaNXjc3zRjpzHYtusgn0sGCnJe5RyVEZ+xjs5gXpW7vjgQy8TJ1RSLggZ3kdduaxOB1LtiI7szvyL/lRvDRY64e9CLXqllMmBYVYo/cc4AiTsuLBLsIHH/wZ+zyNiqxo8QC0YTZb8FECvtg== x-originating-ip: [10.162.157.91] Content-Type: multipart/alternative; boundary="_000_916CE6CF87173740BC8A2CE443096962A6F825008AM1MPN1037mgdn_" MIME-Version: 1.0 X-OriginalArrivalTime: 04 Aug 2011 18:31:57.0732 (UTC) FILETIME=[CAE2FE40:01CC52D4] X-Nokia-AV: Clean Subject: [BEHAVE] Happy Eyeballs and DNS64 not sending synthetic AAAA RRs 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, 04 Aug 2011 18:32:52 -0000 --_000_916CE6CF87173740BC8A2CE443096962A6F825008AM1MPN1037mgdn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, RFC6147 section 5.1.1 says DNS64 "SHOULD NOT" include synthetic AAAA RRs in= the response if real AAAA records are available. Reflecting Happy Eyeballs discussions: should DNS64 actually synthesize AAA= A RRs when real AAAA records are available, the host would then be able to = fall back using IPv4 in case real IPv6 connectivity on the path to dual-sta= ck enabled destination is broken/not-good... I.e. as of now DNS64 by default completely hides dual-stack destinations' I= Pv4 addresses and hence makes it impossible for hosts to fallback to IPv4..= right? Of course returning synthetic AAAA RRs could make hosts accidentally commun= icate through NAT64s.. but we have the tools under work that would help hos= ts to prefer non-synthetic addresses during address selection functions:) If IPv6 and IPv4 path characteristics would be different enough, it might m= ake sense for hosts to do happy eyeballs even when in IPv6-only connection = by triggering both native IPv6 and NAT64-traversing transport sessions.. bu= t hosts can't if DNS64 hides the IPv4 address... except by performing WKP/N= SP discovery as documented and then starting local IPv6 address synthesis p= rocedures for happy eyeballs purposes:) Just some thoughts:) Best regards, Teemu --_000_916CE6CF87173740BC8A2CE443096962A6F825008AM1MPN1037mgdn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

RFC6147 section 5.1.1 says DNS64 “SHOULD NOT&#= 8221; include synthetic AAAA RRs in the response if real AAAA records are a= vailable.

 

Reflecting Happy Eyeballs discussions: should DNS64 = actually synthesize AAAA RRs when real AAAA records are available, the host= would then be able to fall back using IPv4 in case real IPv6 connectivity = on the path to dual-stack enabled destination is broken/not-good…

 

I.e. as of now DNS64 by default completely hides dua= l-stack destinations’ IPv4 addresses and hence makes it impossible fo= r hosts to fallback to IPv4.. right?

 

Of course returning synthetic AAAA RRs could make ho= sts accidentally communicate through NAT64s.. but we have the tools under w= ork that would help hosts to prefer non-synthetic addresses during address = selection functionsJ

 

If IPv6 and IPv4 path characteristics would be diffe= rent enough, it might make sense for hosts to do happy eyeballs even when i= n IPv6-only connection by triggering both native IPv6 and NAT64-traversing = transport sessions.. but hosts can’t if DNS64 hides the IPv4 address… except by performing WKP/NSP discov= ery as documented and then starting local IPv6 address synthesis procedures= for happy eyeballs purposesJ<= o:p>

 

Just some thoughtsJ

 

Best regards,

 

Teemu

--_000_916CE6CF87173740BC8A2CE443096962A6F825008AM1MPN1037mgdn_-- From marc.blanchet@viagenie.ca Thu Aug 4 11:37: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 72BCD11E80B3 for ; Thu, 4 Aug 2011 11:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l1VbNHlTKCVK for ; Thu, 4 Aug 2011 11:37:33 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id B7D5511E8077 for ; Thu, 4 Aug 2011 11:37:33 -0700 (PDT) Received: from [IPv6:2607:fa48:6d5c:a0:58c8:8726:2324:e022] (unknown [IPv6:2607:fa48:6d5c:a0:58c8:8726:2324:e022]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 7E3AA20D22; Thu, 4 Aug 2011 14:37:48 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=windows-1252 From: Marc Blanchet In-Reply-To: <916CE6CF87173740BC8A2CE443096962A6F825@008-AM1MPN1-037.mgdnok.nokia.com> Date: Thu, 4 Aug 2011 14:37:47 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5667E655-22FD-483B-872C-73F9B8667EEC@viagenie.ca> References: <916CE6CF87173740BC8A2CE443096962A6F825@008-AM1MPN1-037.mgdnok.nokia.com> To: X-Mailer: Apple Mail (2.1244.3) Cc: behave@ietf.org Subject: Re: [BEHAVE] Happy Eyeballs and DNS64 not sending synthetic AAAA RRs 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, 04 Aug 2011 18:37:34 -0000 Le 2011-08-04 =E0 14:31, a =E9crit : > Hi, > =20 > RFC6147 section 5.1.1 says DNS64 =93SHOULD NOT=94 include synthetic = AAAA RRs in the response if real AAAA records are available. > =20 > Reflecting Happy Eyeballs discussions: should DNS64 actually = synthesize AAAA RRs when real AAAA records are available, the host would = then be able to fall back using IPv4 I'm not sure I get your point. If we are in a DNS64 scenario, the = network between host and the NAT64, as well as the host itself, is = IPv6-only. Therefore, there is no such "fall back using IPv4". =20 Unless I don't understand your point. Marc. > in case real IPv6 connectivity on the path to dual-stack enabled = destination is broken/not-good=85 > =20 > I.e. as of now DNS64 by default completely hides dual-stack = destinations=92 IPv4 addresses and hence makes it impossible for hosts = to fallback to IPv4.. right? > =20 > Of course returning synthetic AAAA RRs could make hosts accidentally = communicate through NAT64s.. but we have the tools under work that would = help hosts to prefer non-synthetic addresses during address selection = functionsJ > =20 > If IPv6 and IPv4 path characteristics would be different enough, it = might make sense for hosts to do happy eyeballs even when in IPv6-only = connection by triggering both native IPv6 and NAT64-traversing transport = sessions.. but hosts can=92t if DNS64 hides the IPv4 address=85 except = by performing WKP/NSP discovery as documented and then starting local = IPv6 address synthesis procedures for happy eyeballs purposesJ > =20 > Just some thoughtsJ > =20 > Best regards, > =20 > Teemu > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From teemu.savolainen@nokia.com Thu Aug 4 11:46:53 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E0FB5E800C for ; Thu, 4 Aug 2011 11:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tjEL5au0SROv for ; Thu, 4 Aug 2011 11:46:53 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id D72175E8002 for ; Thu, 4 Aug 2011 11:46:52 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p74IkxSD027403; Thu, 4 Aug 2011 21:47:06 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 4 Aug 2011 21:47:04 +0300 Received: from 008-AM1MMR1-005.mgdnok.nokia.com (65.54.30.60) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 4 Aug 2011 20:47:04 +0200 Received: from 008-AM1MPN1-037.mgdnok.nokia.com ([169.254.7.163]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.01.0323.002; Thu, 4 Aug 2011 20:47:03 +0200 From: To: Thread-Topic: [BEHAVE] Happy Eyeballs and DNS64 not sending synthetic AAAA RRs Thread-Index: AcxS1D8ayyrhOKVBTGawrQrX46lAgP//4TCA///dOsA= Date: Thu, 4 Aug 2011 18:47:03 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962A6F877@008-AM1MPN1-037.mgdnok.nokia.com> References: <916CE6CF87173740BC8A2CE443096962A6F825@008-AM1MPN1-037.mgdnok.nokia.com> <5667E655-22FD-483B-872C-73F9B8667EEC@viagenie.ca> In-Reply-To: <5667E655-22FD-483B-872C-73F9B8667EEC@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Company Confidential;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7Ip/CwQNO+Z/4CSkz6RhgChaY1n0HEmVg3epHfhY0ZFwGkloC3jGDKAj+VMd0WguDdKPLnYe8UiY9G8GO2pceavZZX6uY+QBfkLLp9ewp8azj8TeQqjhxMtFwtrDCAPWfFbyRhWR4KNQoG7mv+amIspWRen+QHfQ9jdkOrCiJwAexBlf1iB6PK+CnQPmi8vWHAVrXKyjOnjV9Lbxh7lt7Lc8TdCV7CPfHIsU2KJDO/0AlLbZdhHEcc696M/jQpz7gjZ804SfYMYg77jjvcXBYgvE= x-originating-ip: [10.162.157.91] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 04 Aug 2011 18:47:04.0859 (UTC) FILETIME=[E79396B0:01CC52D6] X-Nokia-AV: Clean Cc: behave@ietf.org Subject: Re: [BEHAVE] Happy Eyeballs and DNS64 not sending synthetic AAAA RRs 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, 04 Aug 2011 18:46:53 -0000 > > RFC6147 section 5.1.1 says DNS64 "SHOULD NOT" include synthetic AAAA > RRs in the response if real AAAA records are available. > > > > Reflecting Happy Eyeballs discussions: should DNS64 actually synthesize= AAAA > RRs when real AAAA records are available, the host would then be able to = fall > back using IPv4 >=20 > I'm not sure I get your point. If we are in a DNS64 scenario, the network > between host and the NAT64, as well as the host itself, is IPv6-only. Th= erefore, > there is no such "fall back using IPv4". >=20 > Unless I don't understand your point. The address family related issues can occur in the access network or elsewh= ere in the Internet, right?=20 If the IPv6 problem is outside of the IPv6-only access network, the eyeball= s might in theory be happier if data would traverse through NAT64 and to th= e IPv4 Internet path to the destination.. I wrote "just some thoughts" because this is theoretical thinking, not some= real life IPv6 transport network problems I would've seen:) Teemu From charliep@wichorus.com Thu Aug 4 11:56:00 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76D3521F8B90 for ; Thu, 4 Aug 2011 11:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RSuLjuodzC84 for ; Thu, 4 Aug 2011 11:55:59 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id DE5BD21F8B5A for ; Thu, 4 Aug 2011 11:55:59 -0700 (PDT) Received: from [138.111.58.2] (helo=[172.17.96.56]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Qp35Y-0001P8-AS for behave@ietf.org; Thu, 04 Aug 2011 14:56:12 -0400 Message-ID: <4E3AEB4A.8080202@wichorus.com> Date: Thu, 04 Aug 2011 11:56:10 -0700 From: "Charles E. Perkins" Organization: WiChorus Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: behave@ietf.org References: <285AA91F41624C6B963A45FECC73F56E@davidPC> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad869f242d49da0c1c41a680fe0677aa24b2350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 138.111.58.2 Subject: Re: [BEHAVE] Closing the behave WG 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, 04 Aug 2011 18:56:00 -0000 Hello folks, I agree that the behave WG "SHOULD NOT" be closed. I really think that NAT[v4-->v6] is important as a perhaps crucial part of the transition story. I understand the case against it to be that "we don't support IPv6-only services for the existing Internet, because IPv4 websites fill the need" -- an argument that I still find to be amazing, coming from experts in the IETF. Regards, Charlie P. On 8/4/2011 8:12 AM, Cameron Byrne wrote: > I disagree that it should be closed and suggest that the nat464 (as > described in pnat, 4v6, and bih) be properly named nat464, generalized, > and brought into this group, softwire is not the right place. It is a > shame that nat464 has such a bad name that the concept has to be veiled > in various other specs > > Cb > From cb.list6@gmail.com Thu Aug 4 12:02: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 D000011E8082 for ; Thu, 4 Aug 2011 12:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.431 X-Spam-Level: X-Spam-Status: No, score=-3.431 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WF7tNfHApBby for ; Thu, 4 Aug 2011 12:02:13 -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 1DEE45E8002 for ; Thu, 4 Aug 2011 12:02:12 -0700 (PDT) Received: by wwe5 with SMTP id 5so1498793wwe.13 for ; Thu, 04 Aug 2011 12:02:27 -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=eK3Fh0Yl9sFeQQbZOiYnhQKJCcwk5u9PoNVv87CweJ4=; b=vmYuLne0vEdm2CZpiAIraEQv6GgNoJAGUApdCYyvhxrjpTu54loKnGjUyqLRPPPsRD FotmRktVtP5BZ5RT1hr2BArYAgnyKP0M1+6lWCrHPqWbSsaR/w3pETVAdwMAVxaRgLkS kR/VukgAtgMeawGgfNgiS/WZFCYSg9sK49Wi8= MIME-Version: 1.0 Received: by 10.216.233.95 with SMTP id o73mr2076105weq.103.1312484547750; Thu, 04 Aug 2011 12:02:27 -0700 (PDT) Received: by 10.216.177.213 with HTTP; Thu, 4 Aug 2011 12:02:27 -0700 (PDT) In-Reply-To: <916CE6CF87173740BC8A2CE443096962A6F877@008-AM1MPN1-037.mgdnok.nokia.com> References: <916CE6CF87173740BC8A2CE443096962A6F825@008-AM1MPN1-037.mgdnok.nokia.com> <5667E655-22FD-483B-872C-73F9B8667EEC@viagenie.ca> <916CE6CF87173740BC8A2CE443096962A6F877@008-AM1MPN1-037.mgdnok.nokia.com> Date: Thu, 4 Aug 2011 12:02:27 -0700 Message-ID: From: Cameron Byrne To: teemu.savolainen@nokia.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: marc.blanchet@viagenie.ca, behave@ietf.org Subject: Re: [BEHAVE] Happy Eyeballs and DNS64 not sending synthetic AAAA RRs 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, 04 Aug 2011 19:02:13 -0000 On Thu, Aug 4, 2011 at 11:47 AM, wrote: >> > RFC6147 section 5.1.1 says DNS64 "SHOULD NOT" include synthetic AAAA >> RRs in the response if real AAAA records are available. >> > >> > Reflecting Happy Eyeballs discussions: should DNS64 actually synthesiz= e AAAA >> RRs when real AAAA records are available, the host would then be able to= fall >> back using IPv4 >> >> I'm not sure I get your point. If we are in a DNS64 scenario, the networ= k >> between host and the NAT64, as well as the host itself, =A0is IPv6-only.= Therefore, >> there is no such "fall back using IPv4". >> >> Unless I don't understand your point. > > The address family related issues can occur in the access network or else= where in the Internet, right? > > If the IPv6 problem is outside of the IPv6-only access network, the eyeba= lls might in theory be happier if data would traverse through NAT64 and to = the IPv4 Internet path to the destination.. > > I wrote "just some thoughts" because this is theoretical thinking, not so= me real life IPv6 transport network problems I would've seen:) > To answer your question, no. NAT64 is here to help the transition to all-ipv6, not to compensate and mask issues where IPv4 is faster than IPv6. Cameron > Teemu > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From ajs@anvilwalrusden.com Thu Aug 4 12: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 AA2C011E80B9 for ; Thu, 4 Aug 2011 12:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSaKd5pEBg9S for ; Thu, 4 Aug 2011 12:06:20 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 31FF711E8087 for ; Thu, 4 Aug 2011 12:06:20 -0700 (PDT) Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id BB5781ECB41C for ; Thu, 4 Aug 2011 19:06:35 +0000 (UTC) Date: Thu, 4 Aug 2011 15:06:32 -0400 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20110804190632.GJ38760@shinkuro.com> References: <916CE6CF87173740BC8A2CE443096962A6F825@008-AM1MPN1-037.mgdnok.nokia.com> <5667E655-22FD-483B-872C-73F9B8667EEC@viagenie.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5667E655-22FD-483B-872C-73F9B8667EEC@viagenie.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [BEHAVE] Happy Eyeballs and DNS64 not sending synthetic AAAA RRs 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, 04 Aug 2011 19:06:20 -0000 On Thu, Aug 04, 2011 at 02:37:47PM -0400, Marc Blanchet wrote: > > I'm not sure I get your point. If we are in a DNS64 scenario, the network between host and the NAT64, as well as the host itself, is IPv6-only. Therefore, there is no such "fall back using IPv4". > Right. Every now and then someone talks about what happens when you use DNS64 in a dual stack environment. The answer is, "Doctor, it hurts when I do this." Don't do it. I get why people want to make DNS64/NAT64 more robust than it may be as defined. But this is an attractive nuisance: it's never really going to work all the way anyway. (The twisty problems of detecting the DNS64 are already illustrating this.) A -- Andrew Sullivan ajs@anvilwalrusden.com From dwing@cisco.com Thu Aug 4 13:24: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 166BE11E8077 for ; Thu, 4 Aug 2011 13:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.824 X-Spam-Level: X-Spam-Status: No, score=-103.824 tagged_above=-999 required=5 tests=[AWL=-1.225, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFI3LkrNei9m for ; Thu, 4 Aug 2011 13:24:36 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4A521F8A71 for ; Thu, 4 Aug 2011 13:24:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1808; q=dns/txt; s=iport; t=1312489492; x=1313699092; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=TPoSLfFIlqhnpUC378lN+5AE9qXIqTUVNbyFYabwUPU=; b=Rn/Jfe6WukGC2s4wwqf8bsSKA0vZNQHzhWSuDUV4DwItoLPy/G0GrjKQ EGLYkiuRi1fevhWNOtIwh0msHVlZBD3m4YV+BhwSKP27j7U+zd3blPqzK rbaLHv4Mq/KYB/LPO9smgDVEXnjTVI2v0pAONlbWR0uhIleBsawQ7GGxG 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvkAAI3/Ok6rRDoJ/2dsb2JhbABDmA6BbI1wd4FAAQEBAQIBAQEBBQoBFxA0EAcBAwIJDgECBAEBAScHGQ4VCgkIAQEEARILF4dKBKJiAZ5mhkIEh1qcJQ X-IronPort-AV: E=Sophos;i="4.67,319,1309737600"; d="scan'208";a="9781867" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-4.cisco.com with ESMTP; 04 Aug 2011 20:24:51 +0000 Received: from dwingWS (sjc-vpn2-56.cisco.com [10.21.112.56]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p74KOomw023430; Thu, 4 Aug 2011 20:24:51 GMT From: "Dan Wing" To: "'Andrew Sullivan'" , References: <916CE6CF87173740BC8A2CE443096962A6F825@008-AM1MPN1-037.mgdnok.nokia.com> <5667E655-22FD-483B-872C-73F9B8667EEC@viagenie.ca> <20110804190632.GJ38760@shinkuro.com> In-Reply-To: <20110804190632.GJ38760@shinkuro.com> Date: Thu, 4 Aug 2011 13:24:50 -0700 Message-ID: <018201cc52e4$901b9690$b052c3b0$@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: AcxS2aXNiP2HDGTDTNOEM2zQM2ExQQACnKmw Content-Language: en-us Subject: Re: [BEHAVE] Happy Eyeballs and DNS64 not sending synthetic AAAA RRs 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, 04 Aug 2011 20:24:37 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Andrew Sullivan > Sent: Thursday, August 04, 2011 12:07 PM > To: behave@ietf.org > Subject: Re: [BEHAVE] Happy Eyeballs and DNS64 not sending synthetic > AAAA RRs > > On Thu, Aug 04, 2011 at 02:37:47PM -0400, Marc Blanchet wrote: > > > > I'm not sure I get your point. If we are in a DNS64 scenario, the > network between host and the NAT64, as well as the host itself, is > IPv6-only. Therefore, there is no such "fall back using IPv4". > > > > Right. Every now and then someone talks about what happens when you > use DNS64 in a dual stack environment. The answer is, "Doctor, it > hurts when I do this." > > Don't do it. > > I get why people want to make DNS64/NAT64 more robust than it may be > as defined. But this is an attractive nuisance: it's never really > going to work all the way anyway. (The twisty problems of detecting > the DNS64 are already illustrating this.) A nuance to this problem is that some networks will have a mix of hosts: (a) IPv4-only, which use a 'normal' DNS server (b) dual stack hosts, which use a 'normal' DNS server (c) IPv6-only hosts, which use a DNS64 server so they can use a NAT64 to visit IPv4-only servers. http://tools.ietf.org/html/draft-wing-behave-dns64-config-03 discusses the pros/cons of a bunch of mechanisms to provide the correct DNS server to all three of those host types. I don't know if there is interest in this problem. (But I find it an interesting problem.) -d > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From stephan.lagerholm@secure64.com Thu Aug 4 14:52: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 10CF211E8078 for ; Thu, 4 Aug 2011 14:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AiwQOijlgEfL for ; Thu, 4 Aug 2011 14:52:27 -0700 (PDT) Received: from zimbra.secure64.com (unknown [64.92.221.189]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF6221F8A4F for ; Thu, 4 Aug 2011 14:52:27 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.secure64.com (Postfix) with ESMTP id 4C5CCB8402; Thu, 4 Aug 2011 15:52:42 -0600 (MDT) X-Virus-Scanned: amavisd-new at secure64.com Received: from zimbra.secure64.com ([127.0.0.1]) by localhost (zimbra.secure64.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q+cI-8HIB06F; Thu, 4 Aug 2011 15:52:31 -0600 (MDT) Received: from exchange.secure64.com (exchange.secure64.com [192.168.254.250]) by zimbra.secure64.com (Postfix) with ESMTPSA id E7AB6B83F4; Thu, 4 Aug 2011 15:52:30 -0600 (MDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=secure64.com; s=2010; t=1312494750; bh=UfSolrFJhz7AOG/9t5Yx3hr9jWOqGH8a8036L9fcqGQ=; h=MIME-Version:Subject:Date:Content-Type:Message-ID:In-Reply-To: References:From:To; b=xBpwhAykWvQu5uKBtufEQTVheoSposVrKPTUKa8M3EVN DXO0HgwLe99e2E9JLRLkULqPIIG9jmQwvlXHIDJ79gvqXv6mEPPEwM4Fg5KHsgvChSs LKwA+JFduP5N4bNewVQ7so6UZQbCSkiLVj+49rJZwwzgrn8Djj5jzZ8TdB3g= Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 4 Aug 2011 15:47:14 -0600 Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0000_01CC52C6.2A0B7D20" Message-ID: In-Reply-To: <018201cc52e4$901b9690$b052c3b0$@com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] Happy Eyeballs and DNS64 not sending synthetic AAAA RRs Thread-Index: AcxS2aXNiP2HDGTDTNOEM2zQM2ExQQACnKmwAAK1SiA= References: <916CE6CF87173740BC8A2CE443096962A6F825@008-AM1MPN1-037.mgdnok.nokia.com> <5667E655-22FD-483B-872C-73F9B8667EEC@viagenie.ca><20110804190632.GJ38760@shinkuro.com> <018201cc52e4$901b9690$b052c3b0$@com> From: "Stephan Lagerholm" To: "Dan Wing" , "Andrew Sullivan" , Subject: Re: [BEHAVE] Happy Eyeballs and DNS64 not sending synthetic AAAA RRs 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, 04 Aug 2011 21:52:28 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0000_01CC52C6.2A0B7D20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thu 8/4/2011 3:25 PM, Dan Wing: > A nuance to this problem is that some networks will have a mix > of hosts: > > (a) IPv4-only, which use a 'normal' DNS server > (b) dual stack hosts, which use a 'normal' DNS server > (c) IPv6-only hosts, which use a DNS64 server so they > can use a NAT64 to visit IPv4-only servers. > > http://tools.ietf.org/html/draft-wing-behave-dns64-config-03 discusses > the pros/cons of a bunch of mechanisms to provide the correct DNS > server to all three of those host types. The technique outlined in the draft doesn't work. Clients will not strictly stick to the "ordered" list: ::ffff:192.0.2.1 # 'normal' DNS server 2001:db8:dddd::1234 # DNS64 server If for example a client is trying to resolve www.dns-will-timeout-for-this-domain.com then the client will switch to the second DNS server in the list. In practice you will have about 50% traffic to each server after a day or so. There are plenty of examples of domains that bind and other nameservers never return an answer for. The right thing to do is to have different policies for the different networks, potentially using views or other similar DNS mechanism. /Stephan Lagerholm ------=_NextPart_000_0000_01CC52C6.2A0B7D20 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITKDCCBDYw ggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRy dXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZ QWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4Mzha MG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3Qg RXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3Qw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz5vIABC054E5b7R+8bA/Ntfojts7e mxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl62y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKe dMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pOrwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCr TLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1BX3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXE XSp9t7TWxO6szRNEt8kr3UMAJfphuWlqWCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPV NFonAgMBAAGjgdwwgdkwHQYDVR0OBBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIB BjAPBgNVHRMBAf8EBTADAQH/MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOk cTBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0 IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 ggEBMA0GCSqGSIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7 rEFsR2CDUbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEU LY69FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvhjJiD yx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYEMIIEijCC A3KgAwIBAgIQJ/TqEfR6hsRunbtuqRcHBzANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoX DTIwMDUzMDEwNDgzOFowga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2Fs dCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0 cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgRW1haWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyOYWk 8n2rQTtiRjeuzcFgdbw5ZflKGkeiucxIzGqY1U01GbmkQuXOSeKKLx580jEHx060g2SdLinVomTE hb2FUTV5pE5okHsceqSSqBfymBXyk8zJpDKVuwxPML2YoAuL5W4bokb6eLyib6tZXqUvz8rabaov 66yhs2qqty5nNYt54R5piOLmRs2gpeq+C852OnoOm+r82idbPXMfIuZIYcZM82mxqC4bttQxICy8 goqOpA6l14lD/BZarx1x1xFZ2rqHDa/68+HC8KTFZ4zW1lQ63gqkugN3s2XI/R7TdGKqGMpokx6h hX71R2XL+E1XKHTSNP8wtu72YjAUjCzrAgMBAAGjgeEwgd4wHwYDVR0jBBgwFoAUrb2YejS0Jvf6 xCZU7wO94CTLVBowHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQEAwIB BjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2Eu Y29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5u ZXQvQWRkVHJ1c3RFeHRlcm5hbENBUm9vdC5jcmwwDQYJKoZIhvcNAQEFBQADggEBABnYiRFvKKym AKLnh8GbkAPbfqES/R7z4vABqZRUQmuaCcSgbdeQkgQDZnlDcfz4b6/bdkXiNxo93eRZBHisHPSD RvN6z1uEci3lRsG6GBEp88tJeYc8um0FnaRtaE+tchQ2qLmx/b/Pf/CkapQ1UI/PgW1Vsd1ZMErf baCcZB9JfO82u/TjafT4OY9arUuFOrcO7dPPDUSi+wS/5C9wjiX7WlQGs9DEvG2N+3MyLOmbhCQt 1n+RemgCUB8OP03pzPW7Z+jcHC47/E7N/gKO46gTCqUmRGXpEPJNUqeu3D7KazJcQWz+9V2g6v/R +puGWG09lkfl/i6VBMIAzI6h8rswggUaMIIEAqADAgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqG SIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFr ZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93 d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdW Yn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1 +uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/ FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40a i6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJ gmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0P AQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRR ME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsGAQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0 cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcw AYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/ RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3NuPukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbR oZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyY PaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1F Tahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV 4ENAQjC+6qXnlNKw/vN1+X9u5zCCBT4wggQmoAMCAQICEQCqieXbTb+XECyYs28RwSsEMA0GCSqG SIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw DgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09N T0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTExMDYxNDAw MDAwMFoXDTEyMDYxMzIzNTk1OVowLzEtMCsGCSqGSIb3DQEJARYec3RlcGhhbi5sYWdlcmhvbG1A c2VjdXJlNjQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnAdEdMkddn0GQ+ok OKJod3Hv35ivPSQArj96FGL0mPtsotACZkiitt/DQmfZO3qS9lCxFsnTFbO956Vj3EiUyijpSCrm Um3VAIIM1QEtzS3zEfUg8YMH0iECf2eKjIFb5MfsCBtT8i6FPBbgkcJaAJCYDNAsqxixxF118tR/ 0s4u0+veG/sWWjFcA1n3bRMY1Fc6b/3OXZL5l7ExylQAPyyQUaOSrPWY083th5M8PuLdLfkdlk5y nX5RUXDLScH4DhitC7JZMn5DDw+ynhnig9qYKFbE8//HcnFvqdv0YRC4fhrIQ2BeMykpM3O6HXiA GQkgnn9DJCIbi7zsPlYaqQIDAQABo4IB7jCCAeowHwYDVR0jBBgwFoAUehNOAHRbxnhjZCfBL+Kg W7x5xXswHQYDVR0OBBYEFLeP6hXrxLxWn2DV69jWEtwA0aA2MA4GA1UdDwEB/wQEAwIFoDAMBgNV HRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEE BAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9z ZWN1cmUuY29tb2RvLm5ldC9DUFMwVwYDVR0fBFAwTjBMoEqgSIZGaHR0cDovL2NybC5jb21vZG9j YS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiAYI KwYBBQUHAQEEfDB6MFIGCCsGAQUFBzAChkZodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9D bGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5jb21vZG9jYS5jb20wKQYDVR0RBCIwIIEec3RlcGhhbi5sYWdlcmhvbG1Ac2VjdXJl NjQuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAX25FQTFsTPhS2D6jKzH+vguHy4xsHonYZPWn97O/J HS+HsjeMejxrW1xRS937oAKW+nMtDBjRQ2yvT7rHYopk6hJUTB1GnoNWJbRRXJLQCkyKAeRl5Zwh 7OY5h3PQgxLxHXlyCBzf4G4RfIjm07bor+fpV30Y2g9SdPiQPiLI3NdKJTS65BGpXMEUOEfiugtY AM0jMQc/JWrR1RY3oYPIqBPTwauuOXBraVguy7nPjxbWntaSvRQkW593LoCRBCQYCg1bM2w83J4n PUAWqmOxRoWjvfHGfqlrFDTIuc7Dy3loqBEPZJHgg5kONUJCu3v6yC26aRjI9to6NjNNbwu+MYIE aDCCBGQCAQEwgakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBD T01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCqieXbTb+X ECyYs28RwSsEMAkGBSsOAwIaBQCgggKTMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTExMDgwNDIxNDcxNFowIwYJKoZIhvcNAQkEMRYEFM1kIGH3hBh0LBOqSbnMJOnz UWauMIG3BgkqhkiG9w0BCQ8xgakwgaYwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG 9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFA MA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZI AWUDBAIBMAoGCCqGSIb3DQIFMIG6BgkrBgEEAYI3EAQxgawwgakwgZMxCzAJBgNVBAYTAkdCMRsw GQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFu ZCBTZWN1cmUgRW1haWwgQ0ECEQCqieXbTb+XECyYs28RwSsEMIG8BgsqhkiG9w0BCRACCzGBrKCB qTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMH U2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGll bnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAKqJ5dtNv5cQLJizbxHBKwQw DQYJKoZIhvcNAQEBBQAEggEAdV9o1FmD59733Rbb3RDVSEITA4qmAhEtHSdZ0QhNh78nXKoP3yOy sXAZIERGyxNExBTfCHkx2CGr/IIyyNGWlDctvg7g69C++w94z1Wj+VRBqpHB8OOCHzTSFvck+5eR A9SKs+sLTnA4phoQJEHCcCh3pXZLtNTMkyG/nxlmIM3K2Vl4e7uheCPF78uDRDYL7Km7ll9wqIjC v9nHCAPJEagwUSy8XCF3X572gjysZrSkoESHq3R3WuZYBS756fYZP0XVJ0Ev6lVEvlt5a3PaHo0D 1UW6faV/x5Ots71i2DRG2dacxfajx+hxGiXz9TOAcS8U7bdwwefk0I139y+l6AAAAAAAAA== ------=_NextPart_000_0000_01CC52C6.2A0B7D20-- From dwing@cisco.com Thu Aug 4 16:55: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 3D65111E8096 for ; Thu, 4 Aug 2011 16:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.738 X-Spam-Level: X-Spam-Status: No, score=-103.738 tagged_above=-999 required=5 tests=[AWL=-1.139, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzKyfvhf+nu9 for ; Thu, 4 Aug 2011 16:55:56 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7520F11E807C for ; Thu, 4 Aug 2011 16:55:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1628; q=dns/txt; s=iport; t=1312502172; x=1313711772; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=WdmuagUExAl7gVtANqA1eYTVAsyc0aRubXfZ3JZ1ec0=; b=Ulr3TpP3MdhPG/VtruYeSdVGBda907/weps0tgkmQZLM2PHfsQaP4ZtY OmPaMo2SA7OuhfYlcanOsxrXMq/MnNqFj6aTaZrO/KooFVtuokHFadWP2 mgn03TRbzlhoBc8mTtX9ywOI6XABKytea2ZhzYfzCXyAeVweBqhvTu6OB s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAAEIxO06rRDoJ/2dsb2JhbABDmBGBbI1wd4FAAQEBAQMICgEXEA88AQMCCQ8CBAEBKAcZIwoJCAEBBAESCxeHTqJBAZ5fhkIEh1qcJQ X-IronPort-AV: E=Sophos;i="4.67,320,1309737600"; d="scan'208";a="9836144" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-1.cisco.com with ESMTP; 04 Aug 2011 23:56:11 +0000 Received: from dwingWS (sjc-vpn2-56.cisco.com [10.21.112.56]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p74NuBjJ024630; Thu, 4 Aug 2011 23:56:11 GMT From: "Dan Wing" To: "'Stephan Lagerholm'" , "'Andrew Sullivan'" , References: <916CE6CF87173740BC8A2CE443096962A6F825@008-AM1MPN1-037.mgdnok.nokia.com> <5667E655-22FD-483B-872C-73F9B8667EEC@viagenie.ca><20110804190632.GJ38760@shinkuro.com> <018201cc52e4$901b9690$b052c3b0$@com> In-Reply-To: Date: Thu, 4 Aug 2011 16:56:09 -0700 Message-ID: <025801cc5302$16353ed0$429fbc70$@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: AcxS2aXNiP2HDGTDTNOEM2zQM2ExQQACnKmwAAK1SiAABMPcMA== Content-Language: en-us Subject: Re: [BEHAVE] Happy Eyeballs and DNS64 not sending synthetic AAAA RRs 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, 04 Aug 2011 23:55:57 -0000 > -----Original Message----- > From: Stephan Lagerholm [mailto:stephan.lagerholm@secure64.com] > Sent: Thursday, August 04, 2011 2:47 PM > To: Dan Wing; Andrew Sullivan; behave@ietf.org > Subject: RE: [BEHAVE] Happy Eyeballs and DNS64 not sending synthetic > AAAA RRs > > Thu 8/4/2011 3:25 PM, Dan Wing: > > A nuance to this problem is that some networks will have a mix > > of hosts: > > > > (a) IPv4-only, which use a 'normal' DNS server > > (b) dual stack hosts, which use a 'normal' DNS server > > (c) IPv6-only hosts, which use a DNS64 server so they > > can use a NAT64 to visit IPv4-only servers. > > > > http://tools.ietf.org/html/draft-wing-behave-dns64-config-03 > discusses > > the pros/cons of a bunch of mechanisms to provide the correct DNS > > server to all three of those host types. > > The technique outlined in the draft doesn't work. Clients will not > strictly > stick to the "ordered" list: > ::ffff:192.0.2.1 # 'normal' DNS server > 2001:db8:dddd::1234 # DNS64 server > > If for example a client is trying to resolve > www.dns-will-timeout-for-this-domain.com then the client will switch to > the > second DNS server in the list. In practice you will have about 50% > traffic > to each server after a day or so. > > There are plenty of examples of domains that bind and other nameservers > never return an answer for. > > The right thing to do is to have different policies for the different > networks, potentially using views or other similar DNS mechanism. Can you write up how to accomplish that? -d > /Stephan Lagerholm From dthaler@microsoft.com Thu Aug 4 17:12: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 BA1F021F85CA for ; Thu, 4 Aug 2011 17:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.553 X-Spam-Level: X-Spam-Status: No, score=-110.553 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fybgNQ8dRWlp for ; Thu, 4 Aug 2011 17:12:50 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id B218E21F85C7 for ; Thu, 4 Aug 2011 17:12:50 -0700 (PDT) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 4 Aug 2011 17:13:03 -0700 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 4 Aug 2011 17:13:02 -0700 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.132]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.01.0323.007; Thu, 4 Aug 2011 17:13:02 -0700 From: Dave Thaler To: "draft-ietf-dime-nat-control@tools.ietf.org" , "dime-chairs@tools.ietf.org" Thread-Topic: My review of draft-ietf-dime-nat-control-09 Thread-Index: AcxTA1pwEoFdHujaQPeAdI8rofSx2A== Date: Fri, 5 Aug 2011 00:13:02 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B1CD01D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: multipart/alternative; boundary="_000_9B57C850BB53634CACEC56EF4853FF653B1CD01DTK5EX14MBXW604w_" MIME-Version: 1.0 Cc: David Harrington , "behave@ietf.org" , "Romascanu, Dan \(Dan\)" Subject: [BEHAVE] My review of draft-ietf-dime-nat-control-09 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 00:12:51 -0000 --_000_9B57C850BB53634CACEC56EF4853FF653B1CD01DTK5EX14MBXW604w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My review of this draft is at http://research.microsoft.com/en-us/um/people/dthaler/draft-ietf-dime-nat-c= ontrol-09.pdf or (same content) http://research.microsoft.com/en-us/um/people/dthaler/draft-ietf-dime-nat-c= ontrol-09.docx High level questions: 1) The model discussed in the draft appears to assume there's only one= NAT device in the domain. In contrast, the models in the Behave WG allow = for multiple. What happens if there are multiple NAT-devices (for failove= r or load balancing or whatever else)? 2) Security seems to be a MAY. Why not a SHOULD or a MUST? Using o= nly a MAY warrants an explanation. 3) There's no mention of DoS attack by filling up logs. Is that a co= ncern? Rest is mostly editorial nits. I also reviewed it for consistency with RFC 4008 and for consistency with d= raft-ietf-behave-lsn-requirements, and I didn't spot any inconsistencies ot= her that in question 1 above. -Dave --_000_9B57C850BB53634CACEC56EF4853FF653B1CD01DTK5EX14MBXW604w_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

My review of this draft is at

http://research.microsoft.= com/en-us/um/people/dthaler/draft-ietf-dime-nat-control-09.pdf

or (same content)

http://research.microsoft= .com/en-us/um/people/dthaler/draft-ietf-dime-nat-control-09.docx

 

High level questions:

1)      The model discussed in the draft appears to assume = there’s only one NAT device in the domain.  In contrast, the mod= els in the Behave WG allow for multiple.   What happens if there = are multiple NAT-devices (for failover or load balancing or whatever else)?

2)      Security seems to be a MAY.   Why not a S= HOULD or a MUST?   Using only a MAY warrants an explanation.=

3)      There’s no mention of DoS attack by filling u= p logs.   Is that a concern?

 

Rest is mostly editorial nits.

 

I also reviewed it for consistency with RFC 4008 and= for consistency with draft-ietf-behave-lsn-requirements, and I didn’= t spot any inconsistencies other that in question 1 above.

 

-Dave

--_000_9B57C850BB53634CACEC56EF4853FF653B1CD01DTK5EX14MBXW604w_-- From simon.perreault@viagenie.ca Fri Aug 5 05:13:43 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0F121F8AE6 for ; Fri, 5 Aug 2011 05:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.375 X-Spam-Level: X-Spam-Status: No, score=-2.375 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bK9XHwdXwunW for ; Fri, 5 Aug 2011 05:13: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 D13B221F8ADC for ; Fri, 5 Aug 2011 05:13:36 -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 19C4220CC4 for ; Fri, 5 Aug 2011 08:13:53 -0400 (EDT) Message-ID: <4E3BDE80.500@viagenie.ca> Date: Fri, 05 Aug 2011 08:13:52 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: "behave@ietf.org" X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [BEHAVE] [CGN reqs] Adjustments to logging section 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, 05 Aug 2011 12:13:43 -0000 All, I received a request to adjust the logging section text as follows. Unless the WG disagrees, this will be in the next revision. Please note that this section is still informative (non normative). OLD: Logging: Traditional allocation creates a lot of log entries. Allocation by random or consecutive port sets create the same number of log entries, but the entries in the case of consecutive port sets are smaller because the sets can be expressed very compactly by indicating a range (e.g. "12000-12009"). NEW: Logging: Traditional allocation creates a lot of log entries, whereas allocation by port sets create much fewer entries. Random and consecutive port sets generate the same number of log entries, but the entries in the case of consecutive port sets are smaller because the sets can be expressed very compactly by indicating a range (e.g. "12000-12009"). Note also that some random port set allocation schemes generate small log entries containing the parameters and algorithm used for the port set generation (see e.g. [I-D.boucadair-pppext-portrange-option]). 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 ajs@anvilwalrusden.com Fri Aug 5 06:10: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 CE93321F8B90 for ; Fri, 5 Aug 2011 06:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fE9mOHjNPaS3 for ; Fri, 5 Aug 2011 06:10:21 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 9D30321F8B09 for ; Fri, 5 Aug 2011 06:10:21 -0700 (PDT) Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 71BFD1ECB41C for ; Fri, 5 Aug 2011 13:10:12 +0000 (UTC) Date: Fri, 5 Aug 2011 09:10:10 -0400 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20110805131009.GD49271@shinkuro.com> References: <916CE6CF87173740BC8A2CE443096962A6F825@008-AM1MPN1-037.mgdnok.nokia.com> <5667E655-22FD-483B-872C-73F9B8667EEC@viagenie.ca> <20110804190632.GJ38760@shinkuro.com> <018201cc52e4$901b9690$b052c3b0$@com> <025801cc5302$16353ed0$429fbc70$@com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <025801cc5302$16353ed0$429fbc70$@com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [BEHAVE] Happy Eyeballs and DNS64 not sending synthetic AAAA RRs 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, 05 Aug 2011 13:10:26 -0000 On Thu, Aug 04, 2011 at 04:56:09PM -0700, Dan Wing wrote: > > The right thing to do is to have different policies for the different > > networks, potentially using views or other similar DNS mechanism. > > Can you write up how to accomplish that? People might want to have a look at http://tools.ietf.org/html/draft-ietf-mif-dns-server-selection-03, which is full of bad ideas that are just slightly less bad than all the other alternatives. Andrew "like democracy" Sullivan -- Andrew Sullivan ajs@anvilwalrusden.com From stephan.lagerholm@secure64.com Fri Aug 5 06:30: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 AB79D21F8BAC for ; Fri, 5 Aug 2011 06:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VMtdtq7e+SB7 for ; Fri, 5 Aug 2011 06:30:40 -0700 (PDT) Received: from zimbra.secure64.com (unknown [64.92.221.189]) by ietfa.amsl.com (Postfix) with ESMTP id 6C35F21F8B8B for ; Fri, 5 Aug 2011 06:30:10 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.secure64.com (Postfix) with ESMTP id CA44AB840C; Fri, 5 Aug 2011 07:30:26 -0600 (MDT) X-Virus-Scanned: amavisd-new at secure64.com Received: from zimbra.secure64.com ([127.0.0.1]) by localhost (zimbra.secure64.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZocQ0T+O827r; Fri, 5 Aug 2011 07:30:26 -0600 (MDT) Received: from exchange.secure64.com (exchange.secure64.com [192.168.254.250]) by zimbra.secure64.com (Postfix) with ESMTPSA id 48062B8409; Fri, 5 Aug 2011 07:30:26 -0600 (MDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=secure64.com; s=2010; t=1312551026; bh=BWyASRlgPlutkNeVngio6SyN7v7cp0GDLawf6uXv7x4=; h=MIME-Version:Subject:Date:Content-Type:Message-ID:In-Reply-To: References:From:To; b=OFuJ8eQug3/EiXC9ScJIBZWGuwoN5dHb5FEN+GGDrZ3m GAbLURH/B1CICJNUgSZd74ix0cgfOZ85pAOzKy5chf4TSiDedJqldy4vQnMks0XnY/K ZeH91/JVeWiguEV85+sws40lOakpXnz6u4Ixx06Gn3njTE4rojXum8JZ23pQ= Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 5 Aug 2011 07:30:12 -0600 Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0025_01CC5349.E4DAE310" Message-ID: In-Reply-To: <20110805131009.GD49271@shinkuro.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] Happy Eyeballs and DNS64 not sending synthetic AAAA RRs Thread-Index: AcxTcS4LEi77BT6YRzOqDuJHocJoXwAAc+fg References: <916CE6CF87173740BC8A2CE443096962A6F825@008-AM1MPN1-037.mgdnok.nokia.com><5667E655-22FD-483B-872C-73F9B8667EEC@viagenie.ca><20110804190632.GJ38760@shinkuro.com><018201cc52e4$901b9690$b052c3b0$@com><025801cc5302$16353ed0$429fbc70$@com> <20110805131009.GD49271@shinkuro.com> From: "Stephan Lagerholm" To: "Andrew Sullivan" , Subject: Re: [BEHAVE] Happy Eyeballs and DNS64 not sending synthetic AAAA RRs 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, 05 Aug 2011 13:30:40 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0025_01CC5349.E4DAE310 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Andrew Sullivan Fri 8/5/2011 8:10 AM: > On Thu, Aug 04, 2011 at 04:56:09PM -0700, Dan Wing wrote: > > > The right thing to do is to have different policies for the > different > > > networks, potentially using views or other similar DNS mechanism. > > > > Can you write up how to accomplish that? > > People might want to have a look at > http://tools.ietf.org/html/draft-ietf-mif-dns-server-selection-03, > which is full of bad ideas that are just slightly less bad than all > the other alternatives. Yes those two drafts should probably "merge" into one, however there is a difference in what they want to accomplish. mif-dns-server-selection assumes additional logic on the host to make an intelligent decision on what DNS server to use when several are available. wing-behave-dns64-config assumes that you only provision the appropriate DNS server to each host so that they can't use the wrong server. Something like wing-behave-dns64-config is needed until all hosts supports mif-dns-server-selection. /Stephan Lagerholm ------=_NextPart_000_0025_01CC5349.E4DAE310 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITKDCCBDYw ggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRy dXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZ QWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4Mzha MG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3Qg RXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3Qw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz5vIABC054E5b7R+8bA/Ntfojts7e mxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl62y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKe dMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pOrwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCr TLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1BX3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXE XSp9t7TWxO6szRNEt8kr3UMAJfphuWlqWCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPV NFonAgMBAAGjgdwwgdkwHQYDVR0OBBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIB BjAPBgNVHRMBAf8EBTADAQH/MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOk cTBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0 IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 ggEBMA0GCSqGSIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7 rEFsR2CDUbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEU LY69FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvhjJiD yx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYEMIIEijCC A3KgAwIBAgIQJ/TqEfR6hsRunbtuqRcHBzANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoX DTIwMDUzMDEwNDgzOFowga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2Fs dCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0 cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgRW1haWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyOYWk 8n2rQTtiRjeuzcFgdbw5ZflKGkeiucxIzGqY1U01GbmkQuXOSeKKLx580jEHx060g2SdLinVomTE hb2FUTV5pE5okHsceqSSqBfymBXyk8zJpDKVuwxPML2YoAuL5W4bokb6eLyib6tZXqUvz8rabaov 66yhs2qqty5nNYt54R5piOLmRs2gpeq+C852OnoOm+r82idbPXMfIuZIYcZM82mxqC4bttQxICy8 goqOpA6l14lD/BZarx1x1xFZ2rqHDa/68+HC8KTFZ4zW1lQ63gqkugN3s2XI/R7TdGKqGMpokx6h hX71R2XL+E1XKHTSNP8wtu72YjAUjCzrAgMBAAGjgeEwgd4wHwYDVR0jBBgwFoAUrb2YejS0Jvf6 xCZU7wO94CTLVBowHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQEAwIB BjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2Eu Y29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5u ZXQvQWRkVHJ1c3RFeHRlcm5hbENBUm9vdC5jcmwwDQYJKoZIhvcNAQEFBQADggEBABnYiRFvKKym AKLnh8GbkAPbfqES/R7z4vABqZRUQmuaCcSgbdeQkgQDZnlDcfz4b6/bdkXiNxo93eRZBHisHPSD RvN6z1uEci3lRsG6GBEp88tJeYc8um0FnaRtaE+tchQ2qLmx/b/Pf/CkapQ1UI/PgW1Vsd1ZMErf baCcZB9JfO82u/TjafT4OY9arUuFOrcO7dPPDUSi+wS/5C9wjiX7WlQGs9DEvG2N+3MyLOmbhCQt 1n+RemgCUB8OP03pzPW7Z+jcHC47/E7N/gKO46gTCqUmRGXpEPJNUqeu3D7KazJcQWz+9V2g6v/R +puGWG09lkfl/i6VBMIAzI6h8rswggUaMIIEAqADAgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqG SIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFr ZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93 d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdW Yn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1 +uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/ FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40a i6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJ gmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0P AQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRR ME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsGAQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0 cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcw AYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/ RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3NuPukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbR oZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyY PaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1F Tahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV 4ENAQjC+6qXnlNKw/vN1+X9u5zCCBT4wggQmoAMCAQICEQCqieXbTb+XECyYs28RwSsEMA0GCSqG SIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw DgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09N T0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTExMDYxNDAw MDAwMFoXDTEyMDYxMzIzNTk1OVowLzEtMCsGCSqGSIb3DQEJARYec3RlcGhhbi5sYWdlcmhvbG1A c2VjdXJlNjQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnAdEdMkddn0GQ+ok OKJod3Hv35ivPSQArj96FGL0mPtsotACZkiitt/DQmfZO3qS9lCxFsnTFbO956Vj3EiUyijpSCrm Um3VAIIM1QEtzS3zEfUg8YMH0iECf2eKjIFb5MfsCBtT8i6FPBbgkcJaAJCYDNAsqxixxF118tR/ 0s4u0+veG/sWWjFcA1n3bRMY1Fc6b/3OXZL5l7ExylQAPyyQUaOSrPWY083th5M8PuLdLfkdlk5y nX5RUXDLScH4DhitC7JZMn5DDw+ynhnig9qYKFbE8//HcnFvqdv0YRC4fhrIQ2BeMykpM3O6HXiA GQkgnn9DJCIbi7zsPlYaqQIDAQABo4IB7jCCAeowHwYDVR0jBBgwFoAUehNOAHRbxnhjZCfBL+Kg W7x5xXswHQYDVR0OBBYEFLeP6hXrxLxWn2DV69jWEtwA0aA2MA4GA1UdDwEB/wQEAwIFoDAMBgNV HRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEE BAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9z ZWN1cmUuY29tb2RvLm5ldC9DUFMwVwYDVR0fBFAwTjBMoEqgSIZGaHR0cDovL2NybC5jb21vZG9j YS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiAYI KwYBBQUHAQEEfDB6MFIGCCsGAQUFBzAChkZodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9D bGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5jb21vZG9jYS5jb20wKQYDVR0RBCIwIIEec3RlcGhhbi5sYWdlcmhvbG1Ac2VjdXJl NjQuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAX25FQTFsTPhS2D6jKzH+vguHy4xsHonYZPWn97O/J HS+HsjeMejxrW1xRS937oAKW+nMtDBjRQ2yvT7rHYopk6hJUTB1GnoNWJbRRXJLQCkyKAeRl5Zwh 7OY5h3PQgxLxHXlyCBzf4G4RfIjm07bor+fpV30Y2g9SdPiQPiLI3NdKJTS65BGpXMEUOEfiugtY AM0jMQc/JWrR1RY3oYPIqBPTwauuOXBraVguy7nPjxbWntaSvRQkW593LoCRBCQYCg1bM2w83J4n PUAWqmOxRoWjvfHGfqlrFDTIuc7Dy3loqBEPZJHgg5kONUJCu3v6yC26aRjI9to6NjNNbwu+MYIE aDCCBGQCAQEwgakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBD T01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCqieXbTb+X ECyYs28RwSsEMAkGBSsOAwIaBQCgggKTMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTExMDgwNTEzMzAxMlowIwYJKoZIhvcNAQkEMRYEFLqLURVWV5XbdTiVmEo7p7Rz 1MDiMIG3BgkqhkiG9w0BCQ8xgakwgaYwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG 9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFA MA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZI AWUDBAIBMAoGCCqGSIb3DQIFMIG6BgkrBgEEAYI3EAQxgawwgakwgZMxCzAJBgNVBAYTAkdCMRsw GQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFu ZCBTZWN1cmUgRW1haWwgQ0ECEQCqieXbTb+XECyYs28RwSsEMIG8BgsqhkiG9w0BCRACCzGBrKCB qTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMH U2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGll bnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAKqJ5dtNv5cQLJizbxHBKwQw DQYJKoZIhvcNAQEBBQAEggEAfLqYuYH9ZwaOi5sb2NHYrwrqVmRESRU5ScYmTLkkUadinCSLW81u DVmqKnFLA5+MMuPCDckvJ9eqUYNNzo4go3q8TvEFWOAmDBfdkztxZIlu4GPW63TGhWgJpS+5/q/e 45Ht7GgTNRvAuWlAd7nIchnaZeDOGeTN2yt79bLtUKEKHJJZaKQWizEdA+2B11LZ9KlKXBLOxsR/ /ncsqnARYykdSCqb8zAdBFLXUZspzTQou8MNPnt3UoHKzVZH9nMLyOtoivakAhEcaullSh/4ClWZ APpryCHN6e3aoHPLsowOvpDhC7DKIlfPLEPjvGwZgxfxXff0q/WKr7OdK++VRgAAAAAAAA== ------=_NextPart_000_0025_01CC5349.E4DAE310-- From ajs@anvilwalrusden.com Fri Aug 5 06:53: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 3B23C21F8661 for ; Fri, 5 Aug 2011 06:53:01 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2WfehcoMPTe7 for ; Fri, 5 Aug 2011 06:53:00 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id AF30E21F865B for ; Fri, 5 Aug 2011 06:53:00 -0700 (PDT) Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 581F81ECB41C for ; Fri, 5 Aug 2011 13:53:18 +0000 (UTC) Date: Fri, 5 Aug 2011 09:53:15 -0400 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20110805135315.GG49271@shinkuro.com> References: <916CE6CF87173740BC8A2CE443096962A6F825@008-AM1MPN1-037.mgdnok.nokia.com> <5667E655-22FD-483B-872C-73F9B8667EEC@viagenie.ca> <20110804190632.GJ38760@shinkuro.com> <018201cc52e4$901b9690$b052c3b0$@com> <025801cc5302$16353ed0$429fbc70$@com> <20110805131009.GD49271@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [BEHAVE] Happy Eyeballs and DNS64 not sending synthetic AAAA RRs 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, 05 Aug 2011 13:53:01 -0000 On Fri, Aug 05, 2011 at 07:30:12AM -0600, Stephan Lagerholm wrote: > > Something like wing-behave-dns64-config is needed until all hosts supports > mif-dns-server-selection. Well, yes, except as you point out it's still at best going to be heuristic, because the technique in draft-wing-behave-dns64-config is quite likely to end up hitting the dns64 anyway. On a slightly different note, Dan, I wonder whether you want to include discussion of a DNSSEC wrinkle. Suppose someone uses the techniques in draft-wing-behave-dns64-config. If they want the upstream resolver to do DNSSEC for them, then there will be yet another problem. When a resolver sets DO=1 and CD=0 and the upstream resolver is validating, then a vaidation failure returns SERVFAIL. A host might reasonably query the next DNS server it has under those circumstances (there's a nasty attack here, of course, if your host has both validating and non-validating upstreams. Don't Do That). In this case, the upstream validation failure will cause the client to start asking the DNS64. Of course, as long as the DNS64 is also validating, it'll return SERVFAIL too, so it might not matter, but it might be worth noting. A -- Andrew Sullivan ajs@anvilwalrusden.com From dean.cheng@huawei.com Thu Aug 4 10:44: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 9CB1D21F8AD6 for ; Thu, 4 Aug 2011 10:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KWh-0sruWtoV for ; Thu, 4 Aug 2011 10:44:20 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id E2ACC21F8AB0 for ; Thu, 4 Aug 2011 10:44:19 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPE00FICZY9WG@szxga05-in.huawei.com> for behave@ietf.org; Fri, 05 Aug 2011 01:44:33 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPE004STZY8KZ@szxga05-in.huawei.com> for behave@ietf.org; Fri, 05 Aug 2011 01:44:33 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml205-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACX54423; Fri, 05 Aug 2011 01:44:30 +0800 (CST) Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 05 Aug 2011 01:44:25 +0800 Received: from SZXEML523-MBX.china.huawei.com ([169.254.3.71]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0270.001; Fri, 05 Aug 2011 01:44:30 +0800 Date: Thu, 04 Aug 2011 17:44:29 +0000 From: Dean cheng In-reply-to: <285AA91F41624C6B963A45FECC73F56E@davidPC> X-Originating-IP: [10.47.135.119] To: David Harrington , "behave@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [BEHAVE] Closing the behave WG Thread-index: AcxSOz1+np/vF0xnTkWaM1paeuvypwAkkPeg X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected X-Mailman-Approved-At: Fri, 05 Aug 2011 09:55:51 -0700 Subject: Re: [BEHAVE] Closing the behave WG 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, 04 Aug 2011 17:44:20 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf > Of David Harrington > Sent: Wednesday, August 03, 2011 5:13 PM > To: behave@ietf.org > Subject: [BEHAVE] Closing the behave WG > > Hi, > > As Responsible Area Director, I have received a request from the > behave WG chairs to consider closing the behave working group, rather > than rechartering to do additional work. > > The chairs and the IESG agree that closing the WG after completing the > current milestones would be a good thing, to signal that the chartered > behave work items supporting transition to IPv6 have been completed. > > During ietf81, the chairs discussed with the working group the > possible closing of the working group. Additional work, such as those > drafts identified in the chairs' slides, can be proposed for > completion in existing working groups (or in new working groups). None > of this would be automatic; the proponents would need to convince an > existing WG to adopt their draft, or would need to convince the IESG a > new working group is justified using the normal methods for requesting > a new working group. The behave chairs have agreed to serve as > technical advisors to working groups that take on such work, if > needed. > > In my opinion, the sense of the room was to support this closure. I disagree with this since actually several people spoke at the mic at the time encouraged the other way around. Dean > > As Responsible area director, I plan to make a decision on WG closure > in the next few weeks, and would like to give the WG mailing list > members a chance to provide feedback on this proposed closure. Please > send substantive comments to the > behave@ietf.org mailing list by 2011-08-15, with the above Subject > line. > > David Harrington > Director, IETF Transport Area > ietfdbh@comcast.net (preferred for ietf) > dbharrington@huaweisymantec.com > +1 603 828 1401 (cell) > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From dthaler@microsoft.com Fri Aug 5 10:00:55 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 995E821F8C45 for ; Fri, 5 Aug 2011 10:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.555 X-Spam-Level: X-Spam-Status: No, score=-110.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3yF528PdEaBi for ; Fri, 5 Aug 2011 10:00:55 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 0ADF421F8C3F for ; Fri, 5 Aug 2011 10:00:55 -0700 (PDT) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 5 Aug 2011 10:01:09 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 5 Aug 2011 10:01:08 -0700 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.132]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0323.007; Fri, 5 Aug 2011 10:01:08 -0700 From: Dave Thaler To: Dean cheng , David Harrington , "behave@ietf.org" Thread-Topic: [BEHAVE] Closing the behave WG Thread-Index: AcxSOz1+np/vF0xnTkWaM1paeuvypwAkkPegADDpt0A= Date: Fri, 5 Aug 2011 17:01:07 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B1CECB1@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <285AA91F41624C6B963A45FECC73F56E@davidPC> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] Closing the behave WG 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, 05 Aug 2011 17:00:55 -0000 Most were people who argued for doing specific work. The discussion in the meeting was not about *not* doing the work. The discussion was about whether they should be in behave or elsewhere. Any arguments for "this work is important" are not arguments for "in behave= " per se. -Dave -----Original Message----- From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of= Dean cheng Sent: Thursday, August 04, 2011 10:44 AM To: David Harrington; behave@ietf.org Subject: Re: [BEHAVE] Closing the behave WG > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On=20 > Behalf Of David Harrington > Sent: Wednesday, August 03, 2011 5:13 PM > To: behave@ietf.org > Subject: [BEHAVE] Closing the behave WG >=20 > Hi, >=20 > As Responsible Area Director, I have received a request from the=20 > behave WG chairs to consider closing the behave working group, rather=20 > than rechartering to do additional work. >=20 > The chairs and the IESG agree that closing the WG after completing the=20 > current milestones would be a good thing, to signal that the chartered=20 > behave work items supporting transition to IPv6 have been completed. >=20 > During ietf81, the chairs discussed with the working group the=20 > possible closing of the working group. Additional work, such as those=20 > drafts identified in the chairs' slides, can be proposed for=20 > completion in existing working groups (or in new working groups). None=20 > of this would be automatic; the proponents would need to convince an=20 > existing WG to adopt their draft, or would need to convince the IESG a=20 > new working group is justified using the normal methods for requesting=20 > a new working group. The behave chairs have agreed to serve as=20 > technical advisors to working groups that take on such work, if=20 > needed. >=20 > In my opinion, the sense of the room was to support this closure. I disagree with this since actually several people spoke at the mic at the = time encouraged the other way around. Dean >=20 > As Responsible area director, I plan to make a decision on WG closure=20 > in the next few weeks, and would like to give the WG mailing list=20 > members a chance to provide feedback on this proposed closure. Please=20 > send substantive comments to the behave@ietf.org mailing list by=20 > 2011-08-15, with the above Subject line. >=20 > David Harrington > Director, IETF Transport Area > ietfdbh@comcast.net (preferred for ietf)=20 > dbharrington@huaweisymantec.com > +1 603 828 1401 (cell) >=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 simon.perreault@viagenie.ca Fri Aug 5 10:08: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 566F421F8BBB for ; Fri, 5 Aug 2011 10:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.488 X-Spam-Level: X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4rTsmVXAaVr6 for ; Fri, 5 Aug 2011 10:08:35 -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 B89CC21F8BA0 for ; Fri, 5 Aug 2011 10:08:35 -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 3130421C25 for ; Fri, 5 Aug 2011 13:08:53 -0400 (EDT) Message-ID: <4E3C23A4.8090600@viagenie.ca> Date: Fri, 05 Aug 2011 13:08:52 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: behave@ietf.org References: <285AA91F41624C6B963A45FECC73F56E@davidPC> <9B57C850BB53634CACEC56EF4853FF653B1CECB1@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B1CECB1@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] Closing the behave WG 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, 05 Aug 2011 17:08:36 -0000 On 2011-08-05 13:01, Dave Thaler wrote: > Most were people who argued for doing specific work. > > The discussion in the meeting was not about *not* doing the work. > The discussion was about whether they should be in behave or elsewhere. > > Any arguments for "this work is important" are not arguments for "in behave" per se. Right. This should be added: the work that people at the mic argued for doing in behave really should be done in behave. We already have the right people here. Other existing working groups are currently busy focusing on other important issues. Chartering a new working group would be useless. Rechartering for the new work seems to me like the best way to make progress. 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 ajs@anvilwalrusden.com Fri Aug 5 10:32: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 D5B2221F8C56 for ; Fri, 5 Aug 2011 10:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 394kLn-KHZvd for ; Fri, 5 Aug 2011 10:32:26 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC0B21F8C52 for ; Fri, 5 Aug 2011 10:32:26 -0700 (PDT) Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 0F0591ECB41C for ; Fri, 5 Aug 2011 17:32:43 +0000 (UTC) Date: Fri, 5 Aug 2011 13:32:41 -0400 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20110805173241.GQ49271@shinkuro.com> References: <285AA91F41624C6B963A45FECC73F56E@davidPC> <4E3A976F.5080404@viagenie.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E3A976F.5080404@viagenie.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [BEHAVE] Closing the behave WG 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, 05 Aug 2011 17:32:27 -0000 Dear colleagues, On Thu, Aug 04, 2011 at 08:58:23AM -0400, Simon Perreault wrote: > Personally, I've stated at the mic that the CGN logging issue is very > important to many people right now and that there is a need for a > standard solution. I think that it is quite likely to be important work. I do not see, however, that it is BEHAVE's problem, and rechartering to make it so seems to me to do violence to the idea of IETF areas. Logging is an operational concern. That problem belongs in the OPS area, where you have some hope of getting the consumers who need this work to participate. The reason I argue this way is motivated by my own experience: DNS64 got _almost no_ review from the DNS community, even though it sorely needed it. There was a last-minute review from the DNS directorate (after months of me yanking as hard as I could on strings to get that review) that turned up several issues that, quite frankly, should have been handled better. But we didn't get that review in time. Logging is even more user-directed than the DNS. Don't do that work here. A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Fri Aug 5 10:44: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 33EBF21F8BE8 for ; Fri, 5 Aug 2011 10:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yiotvgq-buvx for ; Fri, 5 Aug 2011 10:44:26 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id B51ED21F8BAE for ; Fri, 5 Aug 2011 10:44:26 -0700 (PDT) Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id CF1F91ECB41C for ; Fri, 5 Aug 2011 17:44:44 +0000 (UTC) Date: Fri, 5 Aug 2011 13:44:42 -0400 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20110805174442.GR49271@shinkuro.com> References: <285AA91F41624C6B963A45FECC73F56E@davidPC> <4E3AEB4A.8080202@wichorus.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4E3AEB4A.8080202@wichorus.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [BEHAVE] Closing the behave WG 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, 05 Aug 2011 17:44:27 -0000 Dear colleagues, On Thu, Aug 04, 2011 at 11:56:10AM -0700, Charles E. Perkins wrote: > I really think that NAT[v4-->v6] is important as > a perhaps crucial part of the transition story. I would like to see the argument for this. So far, I haven't seen one that I find compelling, and the fact that the chairs received only late submissions for inclusion in the Québec meeting strikes me, at least, as additional evidence for the view that there's nothing anyone really really needs to pursue. The longer a WG lives, the harder it gets to shut it down (I am speaking from really bitter experience here). I have no interest per se in shutting working groups down. But I'd be a lot more convinced that there's urgent work to do here if I saw something that I didn't think was a pipe dream (generalized NAT46 falls into this category in all the forms I've so far seen) or better undertaken elsewhere (such as the logging stuff that I think is indeed important). So a carefully-reasoned argument (I promise to read it and rescind my opinion if it convinces me!) would give me a reason to change my mind. Alternatively, a pointer to some archived message I no doubt missed would provide the clue-bat. But otherwise, I am inclined to support the AD's expressed view that it's time to wind things up. (For my next windmill-trick, I'll lean at DNSEXT.) Curmudgen to the end, A -- Andrew Sullivan ajs@anvilwalrusden.com From simon.perreault@viagenie.ca Fri Aug 5 10:52: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 10D2C21F8BBB for ; Fri, 5 Aug 2011 10:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t5kLkjD3nNUm for ; Fri, 5 Aug 2011 10:52:15 -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 6CC8D21F8C75 for ; Fri, 5 Aug 2011 10:52:15 -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 38FAF21E3E for ; Fri, 5 Aug 2011 13:52:33 -0400 (EDT) Message-ID: <4E3C2DE0.6000509@viagenie.ca> Date: Fri, 05 Aug 2011 13:52:32 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: behave@ietf.org References: <285AA91F41624C6B963A45FECC73F56E@davidPC> <4E3A976F.5080404@viagenie.ca> <20110805173241.GQ49271@shinkuro.com> In-Reply-To: <20110805173241.GQ49271@shinkuro.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] Closing the behave WG 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, 05 Aug 2011 17:52:16 -0000 On 2011-08-05 13:32, Andrew Sullivan wrote: > Logging is an operational concern. That problem belongs in the OPS > area, where you have some hope of getting the consumers who need this > work to participate. I would also be fine with a dedicated working group in the OPS area. I see at least logging, bulk port allocation, and MIB stuff that would be appropriate for the OPS area, probably others I'm forgetting. Actually, is it possible to "move" a working group from one area to another? We're done with the protocol work, now it's time for operational tweaking. Maybe rename to BEHOPS? Or OPSAVE? ;) Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From dthaler@microsoft.com Fri Aug 5 12:59: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 D1EBA21F8610 for ; Fri, 5 Aug 2011 12:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.256 X-Spam-Level: X-Spam-Status: No, score=-110.256 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Oo77emOA1Cv for ; Fri, 5 Aug 2011 12:59:01 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0FA21F8AD3 for ; Fri, 5 Aug 2011 12:59:01 -0700 (PDT) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 5 Aug 2011 12:59:19 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 5 Aug 2011 12:59:19 -0700 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.132]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0323.007; Fri, 5 Aug 2011 12:59:19 -0700 From: Dave Thaler To: Simon Perreault , "behave@ietf.org" Thread-Topic: [BEHAVE] Closing the behave WG Thread-Index: AcxSOz1+np/vF0xnTkWaM1paeuvypwApaAOAADvfCYAAALF5AAAKJK0w Date: Fri, 5 Aug 2011 19:59:18 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B1CF22B@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <285AA91F41624C6B963A45FECC73F56E@davidPC> <4E3A976F.5080404@viagenie.ca> <20110805173241.GQ49271@shinkuro.com> <4E3C2DE0.6000509@viagenie.ca> In-Reply-To: <4E3C2DE0.6000509@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] Closing the behave WG 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, 05 Aug 2011 19:59:01 -0000 Right, having a dedicated WG in the OPS area is the same model followed for multicast (IDMR -> MBoneD) and then for IPv6 (ipng -> v6ops). The difference with IPv6 is that 6man was chartered in addition to v6ops. But in both cases, idmr and ipng closed and new WGs were opened. -Dave -----Original Message----- From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of= Simon Perreault Sent: Friday, August 05, 2011 10:53 AM To: behave@ietf.org Subject: Re: [BEHAVE] Closing the behave WG On 2011-08-05 13:32, Andrew Sullivan wrote: > Logging is an operational concern. That problem belongs in the OPS=20 > area, where you have some hope of getting the consumers who need this=20 > work to participate. I would also be fine with a dedicated working group in the OPS area. I see = at least logging, bulk port allocation, and MIB stuff that would be appropr= iate for the OPS area, probably others I'm forgetting. Actually, is it possible to "move" a working group from one area to another= ? We're done with the protocol work, now it's time for operational tweaking= . Maybe rename to BEHOPS? Or OPSAVE? ;) Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From John.Border@hughes.com Fri Aug 5 13:05: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 5332F5E8007 for ; Fri, 5 Aug 2011 13:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.923 X-Spam-Level: X-Spam-Status: No, score=-1.923 tagged_above=-999 required=5 tests=[AWL=-0.258, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3NcXG+tEcs6r for ; Fri, 5 Aug 2011 13:05:16 -0700 (PDT) Received: from mx0a-00115401.pphosted.com (mx0b-00115401.pphosted.com [67.231.153.13]) by ietfa.amsl.com (Postfix) with ESMTP id A4A6C5E8005 for ; Fri, 5 Aug 2011 13:05:15 -0700 (PDT) Received: from pps.filterd (m0000713 [127.0.0.1]) by mx0b-00115401.pphosted.com (8.14.4/8.14.4) with SMTP id p75JvFSj006587 for ; Fri, 5 Aug 2011 16:05:33 -0400 Received: from hnse1.hns.com (hnse1.hns.com [208.236.67.197]) by mx0b-00115401.pphosted.com with ESMTP id y0prb05n2-1 for ; Fri, 05 Aug 2011 16:05:33 -0400 Received: from mail.hughes.com (expexchub.hughes.com [139.85.54.34]) by hnse1.hns.com (Switch-3.3.4/Switch-3.3.4) with ESMTP id p75K3Xfe009514 for ; Fri, 5 Aug 2011 16:03:34 -0400 (EDT) Received: from EXPEXCVS1.hughes.com ([139.85.54.39]) by expexchub1.hughes.com ([10.33.14.13]) with mapi; Fri, 5 Aug 2011 16:05:31 -0400 From: John Border To: "behave@ietf.org" Date: Fri, 5 Aug 2011 16:05:31 -0400 Thread-Topic: [BEHAVE] Closing the behave WG Thread-Index: AcxSOz1+np/vF0xnTkWaM1paeuvypwApaAOAADvfCYAAALF5AAAKJK0wABQtmfA= Message-ID: <982B8F9A4E5BDC4B89FF7586464DD2190198B0D350AE@EXPEXCVS1.hughes.com> References: <285AA91F41624C6B963A45FECC73F56E@davidPC> <4E3A976F.5080404@viagenie.ca> <20110805173241.GQ49271@shinkuro.com> <4E3C2DE0.6000509@viagenie.ca> <9B57C850BB53634CACEC56EF4853FF653B1CF22B@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B1CF22B@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.211, 0.0.0000 definitions=2011-08-05_06:2011-08-05, 2011-08-05, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1108050154 Subject: Re: [BEHAVE] Closing the behave WG 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, 05 Aug 2011 20:05:17 -0000 NATOPS -----Original Message----- From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of= Dave Thaler Sent: Friday, August 05, 2011 3:59 PM To: Simon Perreault; behave@ietf.org Subject: Re: [BEHAVE] Closing the behave WG Right, having a dedicated WG in the OPS area is the same model followed for multicast (IDMR -> MBoneD) and then for IPv6 (ipng -> v6ops). The difference with IPv6 is that 6man was chartered in addition to v6ops. But in both cases, idmr and ipng closed and new WGs were opened. -Dave -----Original Message----- From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of= Simon Perreault Sent: Friday, August 05, 2011 10:53 AM To: behave@ietf.org Subject: Re: [BEHAVE] Closing the behave WG On 2011-08-05 13:32, Andrew Sullivan wrote: > Logging is an operational concern. That problem belongs in the OPS=20 > area, where you have some hope of getting the consumers who need this=20 > work to participate. I would also be fine with a dedicated working group in the OPS area. I see = at least logging, bulk port allocation, and MIB stuff that would be appropr= iate for the OPS area, probably others I'm forgetting. Actually, is it possible to "move" a working group from one area to another= ? We're done with the protocol work, now it's time for operational tweaking= . Maybe rename to BEHOPS? Or OPSAVE? ;) Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From rpenno@juniper.net Fri Aug 5 13:10: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 A520C21F8B61 for ; Fri, 5 Aug 2011 13:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.478 X-Spam-Level: X-Spam-Status: No, score=-6.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HuPjm73LHUfg for ; Fri, 5 Aug 2011 13:10:17 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id 22E5221F8B5D for ; Fri, 5 Aug 2011 13:09:41 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKTjxOFVDmOxi3EhsPGtkOba1D7Fqb4LEg@postini.com; Fri, 05 Aug 2011 13:10:07 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 5 Aug 2011 13:07:06 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Fri, 5 Aug 2011 16:07:06 -0400 From: Reinaldo Penno To: Dave Thaler , Dean cheng , David Harrington , "behave@ietf.org" Date: Fri, 5 Aug 2011 16:07:04 -0400 Thread-Topic: [BEHAVE] Closing the behave WG Thread-Index: AcxSOz1+np/vF0xnTkWaM1paeuvypwAkkPegADDpt0AABoWSuQ== Message-ID: In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B1CECB1@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.9.0.110114 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] Closing the behave WG 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, 05 Aug 2011 20:10:17 -0000 I would argue to do this work in BEHAVE. We already have a WG, already have experts engaged, a lot of the work is more than just 'OPS' (logging, bis, port block/sets, etc) and there is no need to go through all the steps to have a new WG. In regards to 'moving' to OPS the issue I see is that there are many draft that are related to protocol work. Not sure if they would be served by a WG in OPS. On 8/5/11 10:01 AM, "Dave Thaler" wrote: > Most were people who argued for doing specific work. >=20 > The discussion in the meeting was not about *not* doing the work. > The discussion was about whether they should be in behave or elsewhere. >=20 > Any arguments for "this work is important" are not arguments for "in beha= ve" > per se. >=20 > -Dave >=20 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf = Of > Dean cheng > Sent: Thursday, August 04, 2011 10:44 AM > To: David Harrington; behave@ietf.org > Subject: Re: [BEHAVE] Closing the behave WG >=20 >=20 >=20 >> -----Original Message----- >> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On >> Behalf Of David Harrington >> Sent: Wednesday, August 03, 2011 5:13 PM >> To: behave@ietf.org >> Subject: [BEHAVE] Closing the behave WG >>=20 >> Hi, >>=20 >> As Responsible Area Director, I have received a request from the >> behave WG chairs to consider closing the behave working group, rather >> than rechartering to do additional work. >>=20 >> The chairs and the IESG agree that closing the WG after completing the >> current milestones would be a good thing, to signal that the chartered >> behave work items supporting transition to IPv6 have been completed. >>=20 >> During ietf81, the chairs discussed with the working group the >> possible closing of the working group. Additional work, such as those >> drafts identified in the chairs' slides, can be proposed for >> completion in existing working groups (or in new working groups). None >> of this would be automatic; the proponents would need to convince an >> existing WG to adopt their draft, or would need to convince the IESG a >> new working group is justified using the normal methods for requesting >> a new working group. The behave chairs have agreed to serve as >> technical advisors to working groups that take on such work, if >> needed. >>=20 >> In my opinion, the sense of the room was to support this closure. >=20 > I disagree with this since actually several people spoke at the mic at th= e > time encouraged the other way around. >=20 > Dean >=20 >>=20 >> As Responsible area director, I plan to make a decision on WG closure >> in the next few weeks, and would like to give the WG mailing list >> members a chance to provide feedback on this proposed closure. Please >> send substantive comments to the behave@ietf.org mailing list by >> 2011-08-15, with the above Subject line. >>=20 >> David Harrington >> Director, IETF Transport Area >> ietfdbh@comcast.net (preferred for ietf) >> dbharrington@huaweisymantec.com >> +1 603 828 1401 (cell) >>=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 >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From rpenno@juniper.net Fri Aug 5 13:30: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 6A6FB11E80C1 for ; Fri, 5 Aug 2011 13:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.37 X-Spam-Level: X-Spam-Status: No, score=-6.37 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4XjiWebfLmda for ; Fri, 5 Aug 2011 13:30:45 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 13B7511E80B2 for ; Fri, 5 Aug 2011 13:30:43 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTjxTBTdqr7S67icpN4F8G9aq06wMjhyc@postini.com; Fri, 05 Aug 2011 13:31:02 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 5 Aug 2011 13:27:46 -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; Fri, 5 Aug 2011 16:27:46 -0400 From: Reinaldo Penno To: Simon Perreault , "behave@ietf.org" Date: Fri, 5 Aug 2011 16:27:39 -0400 Thread-Topic: [BEHAVE] [CGN reqs] Adjustments to logging section Thread-Index: AcxTaSv+38wDwAMKSfKhjI3d9dJ/7gARPKg9 Message-ID: In-Reply-To: <4E3BDE80.500@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.9.0.110114 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] [CGN reqs] Adjustments to logging section 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, 05 Aug 2011 20:30:46 -0000 On 8/5/11 5:13 AM, "Simon Perreault" wrote: > All, >=20 > I received a request to adjust the logging section text as follows. > Unless the WG disagrees, this will be in the next revision. Please note > that this section is still informative (non normative). >=20 > OLD: > Logging: Traditional allocation creates a lot of log entries. > Allocation by random or consecutive port sets create the same > number of log entries, but the entries in the case of consecutive > port sets are smaller because the sets can be expressed very > compactly by indicating a range (e.g. "12000-12009"). >=20 > NEW: > Logging: Traditional allocation creates a lot of log entries, > whereas allocation by port sets create much fewer entries. Suggestion "Traditional allocation creates a lot of log entries as compared to allocation by port sets which create much fewer entries." Reasoning is that 'creates a lot of log entries' is subjective. > Random > and consecutive port sets generate the same number of log entries, > but the entries in the case of consecutive port sets are smaller > because the sets can be expressed very compactly by indicating a > range (e.g. "12000-12009"). Note also that some random port set > allocation schemes generate small log entries containing the > parameters and algorithm used for the port set generation (see > e.g. [I-D.boucadair-pppext-portrange-option]). >=20 > Simon From charliep@wichorus.com Fri Aug 5 13:48: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 7F28311E80C7 for ; Fri, 5 Aug 2011 13:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVT095GxgTx5 for ; Fri, 5 Aug 2011 13:48:41 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id 0053611E80C3 for ; Fri, 5 Aug 2011 13:48:41 -0700 (PDT) Received: from [138.111.58.2] (helo=[172.17.96.56]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1QpRKB-0004Dm-He; Fri, 05 Aug 2011 16:48:55 -0400 Message-ID: <4E3C5734.6000009@wichorus.com> Date: Fri, 05 Aug 2011 13:48:52 -0700 From: "Charles E. Perkins" Organization: WiChorus Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Andrew Sullivan References: <285AA91F41624C6B963A45FECC73F56E@davidPC><4E3AEB4A.8080202@wichorus.com> <20110805174442.GR49271@shinkuro.com> In-Reply-To: <20110805174442.GR49271@shinkuro.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad867352a4355b990872ad9192d53d355fd1350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 138.111.58.2 Cc: behave@ietf.org Subject: Re: [BEHAVE] Closing the behave WG 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, 05 Aug 2011 20:48:41 -0000 Hello Andrew, On 8/5/2011 10:44 AM, Andrew Sullivan wrote: > On Thu, Aug 04, 2011 at 11:56:10AM -0700, Charles E. Perkins wrote: > >> I really think that NAT[v4-->v6] is important as >> a perhaps crucial part of the transition story. > > I would like to see the argument for this. If we don't have NAT[v4-->v6], then IPv6-only services are not going to be available to most of the Internet for a really long time. Which, I reckon, means that all services are going to be either IPv4-only or dual-stack for a really long time. It seems to me that requiring all services to have IPv4 addresses is directly counter to the general IETF theme of promoting IPv6 transition. Perhaps instead you meant that there are not any credible possibilities for NAT[v4-->v6]. I am willing to agree that as far as I understand it the alternatives (as of now) have problems of either scalability or maybe vulnerability to DoS attacks. I think these are problems that can be solved, and they would be solved faster in a working group. Looked at another way, if [behave] shuts down without working on NAT[v4-->v6], then it can be seen as sending a strong message that the IETF believes that all services and websites really need to maintain IPv4 addressability ad infinitum [or at least all commercially viable ones]. Regards, Charlie P. From dthaler@microsoft.com Fri Aug 5 14:14:00 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 416EE21F87C6 for ; Fri, 5 Aug 2011 14:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.437 X-Spam-Level: X-Spam-Status: No, score=-110.437 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id duy+Tamw37ug for ; Fri, 5 Aug 2011 14:13:59 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 894D421F87C5 for ; Fri, 5 Aug 2011 14:13:59 -0700 (PDT) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 5 Aug 2011 14:14:17 -0700 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 5 Aug 2011 14:14:17 -0700 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.132]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.01.0323.007; Fri, 5 Aug 2011 14:14:17 -0700 From: Dave Thaler To: Simon Perreault , "behave@ietf.org" Thread-Topic: [BEHAVE] [CGN reqs] Adjustments to logging section Thread-Index: AQHMU2kvdetf1/rpfUSgTvbqUMXRgZUOwoEw Date: Fri, 5 Aug 2011 21:14:17 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B1CF3DF@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <4E3BDE80.500@viagenie.ca> In-Reply-To: <4E3BDE80.500@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] [CGN reqs] Adjustments to logging section 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, 05 Aug 2011 21:14:00 -0000 The third new sentence (which is correct) contradicts the 2nd new sentence which needs to be updated to account for that. -Dave -----Original Message----- From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of= Simon Perreault Sent: Friday, August 05, 2011 5:14 AM To: behave@ietf.org Subject: [BEHAVE] [CGN reqs] Adjustments to logging section All, I received a request to adjust the logging section text as follows. Unless the WG disagrees, this will be in the next revision. Please note tha= t this section is still informative (non normative). OLD: Logging: Traditional allocation creates a lot of log entries. Allocation by random or consecutive port sets create the same number of log entries, but the entries in the case of consecutive port sets are smaller because the sets can be expressed very compactly by indicating a range (e.g. "12000-12009"). NEW: Logging: Traditional allocation creates a lot of log entries, whereas allocation by port sets create much fewer entries. Random and consecutive port sets generate the same number of log entries, but the entries in the case of consecutive port sets are smaller because the sets can be expressed very compactly by indicating a range (e.g. "12000-12009"). Note also that some random port set allocation schemes generate small log entries containing the parameters and algorithm used for the port set generation (see e.g. [I-D.boucadair-pppext-portrange-option]). Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From cb.list6@gmail.com Fri Aug 5 14:18:54 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1926F21F89B8 for ; Fri, 5 Aug 2011 14:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.432 X-Spam-Level: X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NdwzDOKBJKkz for ; Fri, 5 Aug 2011 14:18:53 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 488EA21F89A7 for ; Fri, 5 Aug 2011 14:18:53 -0700 (PDT) Received: by wyg8 with SMTP id 8so1608041wyg.31 for ; Fri, 05 Aug 2011 14:19:10 -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=F0gdiE3QLSdFRmEmblPLvx1EeEuefFgz8rJ76E8soZE=; b=EG0muJjSGsDY7wH0fJyI0uLIydTvOdxUCl/UeaDFozQrnUnapwnp0FWNJbv9vEF8YI cr+DlYmEJoSAvjMljbfGjxI5hLrglSFOhX/TdjGrpfG2cyUaf+hH5ss+pXfawr3oU3kZ 3sxKSSf6zELcJDATag+O19aOMuW1j4Pns46HU= MIME-Version: 1.0 Received: by 10.216.66.149 with SMTP id h21mr2155855wed.103.1312579150319; Fri, 05 Aug 2011 14:19:10 -0700 (PDT) Received: by 10.216.177.213 with HTTP; Fri, 5 Aug 2011 14:19:10 -0700 (PDT) In-Reply-To: <4E3C5734.6000009@wichorus.com> References: <285AA91F41624C6B963A45FECC73F56E@davidPC> <4E3AEB4A.8080202@wichorus.com> <20110805174442.GR49271@shinkuro.com> <4E3C5734.6000009@wichorus.com> Date: Fri, 5 Aug 2011 14:19:10 -0700 Message-ID: From: Cameron Byrne To: "Charles E. Perkins" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: behave@ietf.org, Andrew Sullivan Subject: Re: [BEHAVE] Closing the behave WG 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, 05 Aug 2011 21:18:54 -0000 On Fri, Aug 5, 2011 at 1:48 PM, Charles E. Perkins wrote: > > Hello Andrew, > > On 8/5/2011 10:44 AM, Andrew Sullivan wrote: > >> On Thu, Aug 04, 2011 at 11:56:10AM -0700, Charles E. Perkins wrote: >> >>> I really think that NAT[v4-->v6] is important as >>> a perhaps crucial part of the transition story. >> >> I would like to see the argument for this. > > If we don't have NAT[v4-->v6], then IPv6-only > services are not going to be available to most > of the Internet for a really long time. > > Which, I reckon, means that all services are going > to be either IPv4-only or dual-stack for a really > long time. > > It seems to me that requiring all services to > have IPv4 addresses is directly counter to the > general IETF theme of promoting IPv6 transition. > > Perhaps instead you meant that there are not any > credible possibilities for NAT[v4-->v6]. =A0I am > willing to agree that as far as I understand it > the alternatives (as of now) have problems of either > scalability or maybe vulnerability to DoS attacks. > I think these are problems that can be solved, > and they would be solved faster in a working group. > > Looked at another way, if [behave] shuts down > without working on NAT[v4-->v6], then it can be > seen as sending a strong message that the IETF > believes that all services and websites really need > to maintain IPv4 addressability ad infinitum > [or at least all commercially viable ones]. > I would also like to add the case of NAT464, which is really baked into PNAT, BIH, and 4V6.... but veiled and hobbled in each case. Since the IETF values running code, NAT46 is implemented on the N900 here. http://code.google.com/p/n900ipv6/wiki/Nat64D And, when combined with the T-Mobile USA NAT64, it is a full NAT464 that solves a real problem and meaningfully enables IPv6-only endpoints that have applications that have IPv4 literals or IPv4 sockets. Cameron > Regards, > Charlie P. > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From ajs@anvilwalrusden.com Fri Aug 5 14:24: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 6BA4E21F8A66 for ; Fri, 5 Aug 2011 14:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ChpgJEuNkbn for ; Fri, 5 Aug 2011 14:24:35 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id CAA3F21F8A7B for ; Fri, 5 Aug 2011 14:24:35 -0700 (PDT) Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 56A4B1ECB41C for ; Fri, 5 Aug 2011 21:24:53 +0000 (UTC) Date: Fri, 5 Aug 2011 17:24:49 -0400 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20110805212447.GF51956@shinkuro.com> References: <285AA91F41624C6B963A45FECC73F56E@davidPC> <4E3AEB4A.8080202@wichorus.com> <20110805174442.GR49271@shinkuro.com> <4E3C5734.6000009@wichorus.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E3C5734.6000009@wichorus.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [BEHAVE] Closing the behave WG 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, 05 Aug 2011 21:24:36 -0000 On Fri, Aug 05, 2011 at 01:48:52PM -0700, Charles E. Perkins wrote: > > If we don't have NAT[v4-->v6], then IPv6-only > services are not going to be available to most > of the Internet for a really long time. > > Which, I reckon, means that all services are going > to be either IPv4-only or dual-stack for a really > long time. I think I see our point of disagreement, then. I think that both of those claims are true regardless of whether we have some sort of v4->v6 bag of tricks. If you have a service that you think needs users, you are going to try to hang it off v4 and v6 (and probably x.25 and everything else, if it seems viable). At some point, the v4 traffic won't be worth the cost, I think, and therefore I'm willing to let the v4 transition take (if need be) until the heat death of the universe. Why do we care? > Perhaps instead you meant that there are not any > credible possibilities for NAT[v4-->v6]. I am > willing to agree that as far as I understand it > the alternatives (as of now) have problems of either > scalability or maybe vulnerability to DoS attacks. > I think these are problems that can be solved, > and they would be solved faster in a working group. But so far, nobody has actually proposed anything that would solve them. Instead, what we're getting is yet more spackle on top of patches like NAT64/DNS64. I participated in that effort precisely because I want not-too-awful transition mechanisms to be available for the most pressing cases; now I'm starting to wonder whether this was a good idea. We today have the spectacle of a WG standardizing a special-case name in the DNS in order to get around the DNS64 mess, primarily so that people whose protocols are broken in the first place don't have to fix the mess they left on the carpet (since they've told us that they're going to do this anyway). I am not one of those protocol purist zealots who think that we have to say no to everything because it's ugly. But there is surely a point at which we have to say, "Yes, that's a very hard problem, and we don't have even the hope of a generalized solution, so we shouldn't standardize even more half-measures." We have plenty of half-measures. If someone has a whole measure, then let's hear it. Otherwise, let's stop. These halves are not adding up to wholes, so more half-measures have the perverse effect of undermining interoperability. I'm interested in interoperability. > to maintain IPv4 addressability ad infinitum > [or at least all commercially viable ones]. If businesses waited for the IETF to provide commercial blessing, they'd have ignored NAT44. That's not a problem we have. We are not the priests of the Internet. (If anything, we're the water and sewer division. Let's worry about whether the relevant substances are flowing, and to where!) A -- Andrew Sullivan ajs@anvilwalrusden.com From brian.e.carpenter@gmail.com Fri Aug 5 14:25:12 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0930D21F8A66 for ; Fri, 5 Aug 2011 14:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZ5UhkO8+kbH for ; Fri, 5 Aug 2011 14:25:11 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3DFC021F8551 for ; Fri, 5 Aug 2011 14:25:11 -0700 (PDT) Received: by fxe6 with SMTP id 6so3924348fxe.31 for ; Fri, 05 Aug 2011 14:25:29 -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=h+2i1BQRVqgubujyWQl26iyAnFwGCkkttQtouh4eO8s=; b=RLhISZl2PAQfEFRY8TMt7N2UcbW+fmovouukMLigpNZTU9UEO0Sr9iAi7/1lccEr9x ibmHwqXqQ9p2ENjFz7MWaSUGpOQNb32qf/9CGW+tXt+3+DeSi+oAheBh8QfT+p3DzOu3 DKSVy1X8lf/rAT+TJdeqS72tVodmyYor+bsBg= Received: by 10.204.49.200 with SMTP id w8mr914772bkf.195.1312579529029; Fri, 05 Aug 2011 14:25:29 -0700 (PDT) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id x1sm598137fah.2.2011.08.05.14.25.25 (version=SSLv3 cipher=OTHER); Fri, 05 Aug 2011 14:25:28 -0700 (PDT) Message-ID: <4E3C5FBE.4090904@gmail.com> Date: Sat, 06 Aug 2011 09:25:18 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Charles E. Perkins" References: <285AA91F41624C6B963A45FECC73F56E@davidPC><4E3AEB4A.8080202@wichorus.com> <20110805174442.GR49271@shinkuro.com> <4E3C5734.6000009@wichorus.com> In-Reply-To: <4E3C5734.6000009@wichorus.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: behave@ietf.org, Andrew Sullivan Subject: Re: [BEHAVE] Closing the behave WG 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, 05 Aug 2011 21:25:12 -0000 Charlie, On 2011-08-06 08:48, Charles E. Perkins wrote: > > Hello Andrew, > > On 8/5/2011 10:44 AM, Andrew Sullivan wrote: > >> On Thu, Aug 04, 2011 at 11:56:10AM -0700, Charles E. Perkins wrote: >> >>> I really think that NAT[v4-->v6] is important as >>> a perhaps crucial part of the transition story. >> >> I would like to see the argument for this. > > If we don't have NAT[v4-->v6], then IPv6-only > services are not going to be available to most > of the Internet for a really long time. > > Which, I reckon, means that all services are going > to be either IPv4-only or dual-stack for a really > long time. Correct. I've regarded that as a given for some years now. I wouldn't put any of my own money into an application service provider who proposed to go IPv6-only in the near future. > It seems to me that requiring all services to > have IPv4 addresses is directly counter to the > general IETF theme of promoting IPv6 transition. I try to avoid the word "transition" and focus on co-existence. Also, the "universal deployment of IPv6" does not imply "deployment of IPv6-only services". So I'm not sure that this is a current goal for the IETF. It seems like something that lies quite some years in the future. Regards Brian > Perhaps instead you meant that there are not any > credible possibilities for NAT[v4-->v6]. I am > willing to agree that as far as I understand it > the alternatives (as of now) have problems of either > scalability or maybe vulnerability to DoS attacks. > I think these are problems that can be solved, > and they would be solved faster in a working group. > > Looked at another way, if [behave] shuts down > without working on NAT[v4-->v6], then it can be > seen as sending a strong message that the IETF > believes that all services and websites really need > to maintain IPv4 addressability ad infinitum > [or at least all commercially viable ones]. > > Regards, > Charlie P. > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From rdroms.ietf@gmail.com Fri Aug 5 14:29: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 6BBFE21F8B24 for ; Fri, 5 Aug 2011 14:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.499 X-Spam-Level: X-Spam-Status: No, score=-103.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5O+qPo--c0y for ; Fri, 5 Aug 2011 14:29:39 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id BF35421F8B23 for ; Fri, 5 Aug 2011 14:29:39 -0700 (PDT) Received: by qyk34 with SMTP id 34so563574qyk.10 for ; Fri, 05 Aug 2011 14:29:58 -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=9+MMbZDgb7ZAi3wb+dHky23qLryYEGDi8gaerIZloCo=; b=SoVB2GAb8QvSP02kxWwG1CafC/XBvKr10SA2uL2D44Ie2VrDLp4iMhyDJ+frDy5+cI jRuI8btYbI7m6Q+dWQmfkERLVQdsVhtHzAUtb7lVHlEBkXEwNx341E7aYz8ZL8bKjLjQ A+x2Lo11iMzMxXr9KGO269OfYXWpMcU1EUpyY= Received: by 10.224.187.197 with SMTP id cx5mr2027132qab.349.1312579796336; Fri, 05 Aug 2011 14:29:56 -0700 (PDT) Received: from bxb-rdroms-8712.cisco.com (198-135-0-233.cisco.com [198.135.0.233]) by mx.google.com with ESMTPS id q9sm2434438qct.8.2011.08.05.14.29.54 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Aug 2011 14:29:55 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: <4E3C5FBE.4090904@gmail.com> Date: Fri, 5 Aug 2011 17:29:53 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <285AA91F41624C6B963A45FECC73F56E@davidPC><4E3AEB4A.8080202@wichorus.com> <20110805174442.GR49271@shinkuro.com> <4E3C5734.6000009@wichorus.com> <4E3C5FBE.4090904@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1084) Cc: "Charles E. Perkins" , behave@ietf.org, Andrew Sullivan Subject: Re: [BEHAVE] Closing the behave WG 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, 05 Aug 2011 21:29:40 -0000 Brian, et al., On Aug 5, 2011, at 5:25 PM 8/5/11, Brian E Carpenter wrote: > Charlie, >=20 > On 2011-08-06 08:48, Charles E. Perkins wrote: >>=20 >> Hello Andrew, >>=20 >> On 8/5/2011 10:44 AM, Andrew Sullivan wrote: >>=20 >>> On Thu, Aug 04, 2011 at 11:56:10AM -0700, Charles E. Perkins wrote: >>>=20 >>>> I really think that NAT[v4-->v6] is important as >>>> a perhaps crucial part of the transition story. >>>=20 >>> I would like to see the argument for this. >>=20 >> If we don't have NAT[v4-->v6], then IPv6-only >> services are not going to be available to most >> of the Internet for a really long time. >>=20 >> Which, I reckon, means that all services are going >> to be either IPv4-only or dual-stack for a really >> long time. >=20 > Correct. I've regarded that as a given for some years now. > I wouldn't put any of my own money into an application service > provider who proposed to go IPv6-only in the near future. >=20 >> It seems to me that requiring all services to >> have IPv4 addresses is directly counter to the >> general IETF theme of promoting IPv6 transition. >=20 > I try to avoid the word "transition" and focus on co-existence. > Also, the "universal deployment of IPv6" does not imply > "deployment of IPv6-only services". So I'm not sure that this > is a current goal for the IETF. It seems like something that > lies quite some years in the future. Seems to me, then, we can comfortably postpone serious work on = NAT[v4-->v6] until (and if) we find we really need it... - Ralph >=20 > Regards >=20 > Brian >=20 >> Perhaps instead you meant that there are not any >> credible possibilities for NAT[v4-->v6]. I am >> willing to agree that as far as I understand it >> the alternatives (as of now) have problems of either >> scalability or maybe vulnerability to DoS attacks. >> I think these are problems that can be solved, >> and they would be solved faster in a working group. >>=20 >> Looked at another way, if [behave] shuts down >> without working on NAT[v4-->v6], then it can be >> seen as sending a strong message that the IETF >> believes that all services and websites really need >> to maintain IPv4 addressability ad infinitum >> [or at least all commercially viable ones]. >>=20 >> Regards, >> Charlie P. >>=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 charliep@wichorus.com Fri Aug 5 16:27: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 1821621F85EE for ; Fri, 5 Aug 2011 16:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SgnXa-fvaQ4W for ; Fri, 5 Aug 2011 16:27:50 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id 60B2A21F85EC for ; Fri, 5 Aug 2011 16:27:50 -0700 (PDT) Received: from [138.111.58.2] (helo=[172.17.96.56]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1QpToG-0004Op-9L; Fri, 05 Aug 2011 19:28:08 -0400 Message-ID: <4E3C7C85.8060602@wichorus.com> Date: Fri, 05 Aug 2011 16:28:05 -0700 From: "Charles E. Perkins" Organization: WiChorus Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Andrew Sullivan References: <285AA91F41624C6B963A45FECC73F56E@davidPC><4E3AEB4A.8080202@wichorus.com> <20110805174442.GR49271@shinkuro.com><4E3C5734.6000009@wichorus.com> <20110805212447.GF51956@shinkuro.com> In-Reply-To: <20110805212447.GF51956@shinkuro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad866f862d967ab2832bf3a0a22ff6bd326c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 138.111.58.2 Cc: behave@ietf.org Subject: Re: [BEHAVE] Closing the behave WG 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, 05 Aug 2011 23:27:51 -0000 Hello Andrew and all, Follow-up below... On 8/5/2011 2:24 PM, Andrew Sullivan wrote: > On Fri, Aug 05, 2011 at 01:48:52PM -0700, Charles E. Perkins wrote: >> >> If we don't have NAT[v4-->v6], then IPv6-only >> services are not going to be available to most >> of the Internet for a really long time. >> >> Which, I reckon, means that all services are going >> to be either IPv4-only or dual-stack for a really >> long time. > > ......... both of > those claims are true regardless of whether we have some sort of > v4->v6 bag of tricks. See below, but you have to admit if we insist on not supporting v4-->v6 then we are essentially mandating those two results. > If you have a service that you think needs > users, you are going to try to hang it off v4 and v6 (and probably > x.25 and everything else, if it seems viable). Unfortunately, that might include practically all websites except the ones that wish to intentionally restrict access. Then we end up where it's no longer so democratic to offer a website, because the hosting site has to have a v4 address. Oh, but wait, then the website owner can pay extra for that. Makes a good business for prolonging the requirement for IPv4, and moreover a business that gets better over time as more and more people wish to have some sort of widely available Internet communication endpoint (at least until the heat death of the universe). I guess I had hoped things could be better. > At some point, the v4 > traffic won't be worth the cost, I think, and therefore I'm willing to > let the v4 transition take (if need be) until the heat death of the > universe. Why do we care? O.K. so I am not really concerned about how long it takes for IPv4 traffic to disappear. I am much more concerned about how long the IETF will practically mandate IPv4 addressability for all new websites (and whatever the future paradigm for publishing content or offering service might be). I hope you will tell me that you do see the difference. >> Perhaps instead you meant that there are not any >> credible possibilities for NAT[v4-->v6]. ... >> I think these are problems that can be solved, >> and they would be solved faster in a working group. > > But so far, nobody has actually proposed anything that would solve > them. Ouch. > Instead, what we're getting is yet more spackle on top of > patches like NAT64/DNS64. Perhaps I am missing the point, but if an IPv4 host wants to resolve the name of an IPv6-only host, isn't DNS tautologically required to help out with that? > .............................................. there is surely a > point at which we have to say, "Yes, that's a very hard problem, and > we don't have even the hope of a generalized solution, so we shouldn't > standardize even more half-measures." Hmmm... Just this morning, someone quoted Mark Townsley as saying: "If you have something that solves 90% of a problem for 90% of the population, you have a product to ship" But your answer presumes that we don't even have the hope, and given that of course it is futile [...case closed]. > ... These halves are not adding up to wholes, so > more half-measures have the perverse effect of undermining > interoperability. I'm interested in interoperability. I think you will get universal agreement on the latter. If existing efforts could not possibly add up to a better solution that would _enhance_ interoperability, I would be in your camp. But I expect better results are very likely to be achievable. >> to maintain IPv4 addressability ad infinitum >> [or at least all commercially viable ones]. > > If businesses waited for the IETF to provide commercial blessing, > they'd have ignored NAT44. That's not a problem we have. We are not > the priests of the Internet. I thought that the IETF neglect to specify interoperable NAT44 was nearly universally considered to be a serious failure, not to be repeated. Am I wrong? Regards, Charlie P. From charliep@wichorus.com Fri Aug 5 16:28: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 361ED21F865E for ; Fri, 5 Aug 2011 16:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D41V7san3lSt for ; Fri, 5 Aug 2011 16:28:35 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id B75F921F884C for ; Fri, 5 Aug 2011 16:28:35 -0700 (PDT) Received: from [138.111.58.2] (helo=[172.17.96.56]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1QpToz-0002vj-Rz; Fri, 05 Aug 2011 19:28:54 -0400 Message-ID: <4E3C7CAF.2060406@wichorus.com> Date: Fri, 05 Aug 2011 16:28:47 -0700 From: "Charles E. Perkins" Organization: WiChorus Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Brian E Carpenter References: <285AA91F41624C6B963A45FECC73F56E@davidPC><4E3AEB4A.8080202@wichorus.com><20110805174442.GR49271@shinkuro.com> <4E3C5734.6000009@wichorus.com> <4E3C5FBE.4090904@gmail.com> In-Reply-To: <4E3C5FBE.4090904@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad8676af335e71d28f27f0e26d8aa40ccd87350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 138.111.58.2 Cc: behave@ietf.org Subject: Re: [BEHAVE] Closing the behave WG 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, 05 Aug 2011 23:28:36 -0000 Hello Brian, I haven't replied to any of your messages for an extremely long time :-) On 8/5/2011 2:25 PM, Brian E Carpenter wrote: >> ... all services are going >> to be either IPv4-only or dual-stack for a really >> long time. > > Correct. I've regarded that as a given for some years now. > I wouldn't put any of my own money into an application service > provider who proposed to go IPv6-only in the near future. I wouldn't either! In fact, it would be really wrong to go IPv6-only until after either the heat death of the universe, or until there is a solution to the [NAT v4-->v6] problem. Even if we start today in [behave], we won't have a standard for at least a year or two. But we can start because I think the problem is really pretty well understood. > I try to avoid the word "transition" and focus on co-existence. > Also, the "universal deployment of IPv6" does not imply > "deployment of IPv6-only services". So I'm not sure that this > is a current goal for the IETF. It seems like something that > lies quite some years in the future. Well, my point is mostly if we fail to do anything today, we are helping to push the "deployment of IPv6-only services" even farther into the future. Moreover, that enabling such deployment would be very helpful to enable more and more people to offer services/websites/webcams/content etc... over our now-even-more-rapidly-expanding Internet. There is a famous IBM joke about planning for new bridges that fits here. Regards, Charlie P. From dwing@cisco.com Fri Aug 5 17:31: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 2B2A821F8B02 for ; Fri, 5 Aug 2011 17:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.527 X-Spam-Level: X-Spam-Status: No, score=-103.527 tagged_above=-999 required=5 tests=[AWL=-1.155, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r855XgDnE1Fu for ; Fri, 5 Aug 2011 17:31:07 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id A67DE21F8ACE for ; Fri, 5 Aug 2011 17:31:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2757; q=dns/txt; s=iport; t=1312590684; x=1313800284; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=LH+tyJI3Nkzfvcp7+xSyzifbaNn2kIU9psTEkN51b+w=; b=UvaGU9C19RyXopByc8G7A8Dgi1YAv0mhTXsXhY6xCWb5KN8heWTLJLn2 BSni46FcMmB/jFiOWWqF3ITCV0rtTWpcMzaZ0wQUMOsdVjJZDOxB2FQgD gbmpZttVnYRKv4ay7gSy6NR85K5zuqBlSCYRHpx8xRtuE+19DdUljtIl3 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am4BAK+KPE6rRDoH/2dsb2JhbABCmB2BbIZSgUyFQXeBQAEBAQECAQEBAQUKARQDEDQQBwEDAgkPAgQBASgHGQ4VCgkIAQEEARILF4dLBKA1AZ5OhkYEh1ycLA X-IronPort-AV: E=Sophos;i="4.67,326,1309737600"; d="scan'208";a="10294250" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-6.cisco.com with ESMTP; 06 Aug 2011 00:31:22 +0000 Received: from dwingWS (sjc-vpn6-1795.cisco.com [10.21.127.3]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p760VL8K032754; Sat, 6 Aug 2011 00:31:21 GMT From: "Dan Wing" To: "'Simon Perreault'" , References: <4E3BDE80.500@viagenie.ca> In-Reply-To: <4E3BDE80.500@viagenie.ca> Date: Fri, 5 Aug 2011 17:31:21 -0700 Message-ID: <02b201cc53d0$2aa1c6d0$7fe55470$@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: AcxTaSvkKYgHn6+ATp2h2jnBbWV9lAAZhggQ Content-Language: en-us Subject: Re: [BEHAVE] [CGN reqs] Adjustments to logging section 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, 06 Aug 2011 00:31:08 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Simon Perreault > Sent: Friday, August 05, 2011 5:14 AM > To: behave@ietf.org > Subject: [BEHAVE] [CGN reqs] Adjustments to logging section > > All, > > I received a request to adjust the logging section text as follows. > Unless the WG disagrees, this will be in the next revision. Please note > that this section is still informative (non normative). > > OLD: > Logging: Traditional allocation creates a lot of log entries. > Allocation by random or consecutive port sets create the same > number of log entries, but the entries in the case of consecutive > port sets are smaller because the sets can be expressed very > compactly by indicating a range (e.g. "12000-12009"). > > NEW: > Logging: Traditional allocation creates a lot of log entries, > whereas allocation by port sets create much fewer entries. > Random > and consecutive port sets generate the same number of log > entries, > but the entries in the case of consecutive port sets are smaller > because the sets can be expressed very compactly by indicating a > range (e.g. "12000-12009"). Note also that some random port set > allocation schemes generate small log entries containing the > parameters and algorithm used for the port set generation (see > e.g. [I-D.boucadair-pppext-portrange-option]). Much of the logging savings attributed to bulk port schemes is because the destination isn't logged. To avoid identifying too many subscribers, this relies on the servers logging the source port. So, Section 5 should add something like: Some of the log reduction of bulk port allocation is because the destination is not logged. As with random port allocation (Section 4), if the destination is not logged the servers need to log the source port [RFC6302]. If the servers do not log the source port, it is impossible to distinguish between users of that same IP address accessing that server. You might consider generalizing this a bit more and creating a small section titled something like "User Identification if Destination Is Not Logged", and providing forward references from Section 4 and Section 5 to that new section -- as it applies equally to both. -d > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From simon.perreault@viagenie.ca Fri Aug 5 18:19:09 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 465F921F886A for ; Fri, 5 Aug 2011 18:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.386 X-Spam-Level: X-Spam-Status: No, score=-2.386 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Us3aDjUlGByP for ; Fri, 5 Aug 2011 18:18:59 -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 BE85E21F8867 for ; Fri, 5 Aug 2011 18:18:59 -0700 (PDT) Received: from [192.168.1.49] (modemcable053.145-202-24.mc.videotron.ca [24.202.145.53]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 3647720EFE; Fri, 5 Aug 2011 21:19:18 -0400 (EDT) Message-ID: <4E3C9693.1090200@viagenie.ca> Date: Fri, 05 Aug 2011 21:19:15 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Dan Wing References: <4E3BDE80.500@viagenie.ca> <02b201cc53d0$2aa1c6d0$7fe55470$@com> In-Reply-To: <02b201cc53d0$2aa1c6d0$7fe55470$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: behave@ietf.org Subject: Re: [BEHAVE] [CGN reqs] Adjustments to logging section 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, 06 Aug 2011 01:19:09 -0000 Le 05/08/2011 8:31 PM, Dan Wing a écrit : > Much of the logging savings attributed to bulk port schemes is because > the destination isn't logged. I'm not following you. It's also possible to not log the destination with the traditional port allocation scheme, and bulk port allocation would still generate much fewer log entries. So I don't see how your proposed text is accurate. Simon From dwing@cisco.com Fri Aug 5 18:34: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 995A911E807B for ; Fri, 5 Aug 2011 18:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.372 X-Spam-Level: X-Spam-Status: No, score=-102.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHuJnQewr-Sc for ; Fri, 5 Aug 2011 18:34:56 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id BDD5021F88A1 for ; Fri, 5 Aug 2011 18:34:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=943; q=dns/txt; s=iport; t=1312594516; x=1313804116; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=Z5fPWo105xLoiOVJWDMhSUZKRkE1hzPjFo2I2fLcShw=; b=KoSnw1KCO//pRc2a1OkuM82ppPCiOjukuMa6XkaMDRHvJOkuDKYtKMsX vndAD50MKAO5/8EOFwJaa86fjhQ5naa1CtOniIss7NgyXgs3oiMUzdk/2 JKiQ72GW2RKUDyJEaBBb0PBouLwEj6pJp/Mg3tn2rP1+FA/K23hJlxET4 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuQAAPqYPE6tJV2a/2dsb2JhbABCmB+BbI1fd4FAAQEBAQMICgEXRAsMAQMCCQ8CBAEBKAcZIwoJCAEBBBMLF6gyAZ5LhkYEhy0vnCw X-IronPort-AV: E=Sophos;i="4.67,326,1309737600"; d="scan'208";a="10313058" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 06 Aug 2011 01:35:14 +0000 Received: from dwingWS (sjc-vpn6-1795.cisco.com [10.21.127.3]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p761ZEoC021104; Sat, 6 Aug 2011 01:35:14 GMT From: "Dan Wing" To: "'Simon Perreault'" References: <4E3BDE80.500@viagenie.ca> <02b201cc53d0$2aa1c6d0$7fe55470$@com> <4E3C9693.1090200@viagenie.ca> In-Reply-To: <4E3C9693.1090200@viagenie.ca> Date: Fri, 5 Aug 2011 18:35:13 -0700 Message-ID: <02c701cc53d9$16ecfb60$44c6f220$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxT1t6fvmUA9x63QrSKrA+/KO72EwAAfwxg Content-Language: en-us Cc: behave@ietf.org Subject: Re: [BEHAVE] [CGN reqs] Adjustments to logging section 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, 06 Aug 2011 01:34:57 -0000 > -----Original Message----- > From: Simon Perreault [mailto:simon.perreault@viagenie.ca] > Sent: Friday, August 05, 2011 6:19 PM > To: Dan Wing > Cc: behave@ietf.org > Subject: Re: [BEHAVE] [CGN reqs] Adjustments to logging section >=20 > Le 05/08/2011 8:31 PM, Dan Wing a =E9crit : > > Much of the logging savings attributed to bulk port schemes is > because > > the destination isn't logged. >=20 > I'm not following you. It's also possible to not log the destination > with the traditional port allocation scheme, and bulk port allocation > would still generate much fewer log entries. So I don't see how your > proposed text is accurate. What you say is true. But I have never hard of anyone considering=20 bulk (source) port allocation combined with destination logging -- there's no logging-related purpose (although there may well be=20 other purposes, but none of which have come up on the mailing list). -d From ajs@anvilwalrusden.com Fri Aug 5 18:50: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 557D911E8088 for ; Fri, 5 Aug 2011 18:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKfamjOxARsa for ; Fri, 5 Aug 2011 18:50:43 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id AC55611E807E for ; Fri, 5 Aug 2011 18:50:43 -0700 (PDT) Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 1B9931ECB41C for ; Sat, 6 Aug 2011 01:51:02 +0000 (UTC) Date: Fri, 5 Aug 2011 21:50:59 -0400 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20110806015059.GB53096@shinkuro.com> References: <285AA91F41624C6B963A45FECC73F56E@davidPC> <4E3AEB4A.8080202@wichorus.com> <20110805174442.GR49271@shinkuro.com> <4E3C5734.6000009@wichorus.com> <20110805212447.GF51956@shinkuro.com> <4E3C7C85.8060602@wichorus.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E3C7C85.8060602@wichorus.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [BEHAVE] Closing the behave WG 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, 06 Aug 2011 01:50:44 -0000 On Fri, Aug 05, 2011 at 04:28:05PM -0700, Charles E. Perkins wrote: > Then we end up where it's no longer so democratic to offer > a website, because the hosting site has to have a v4 address. This seems to be conflating "someone still has to connect via IPv4" with "most people have to connect via IPv4". I don't notice a large number of people still trying to connect via X.25, even though it's still available and was once considerably more widely supported than IPv4. > it takes for IPv4 traffic to disappear. I am much > more concerned about how long the IETF will practically > mandate IPv4 addressability for all new websites (and I just don't get how the IETF is mandating anything (never mind how seriouslt the IETF's mandates are taken. Given another project -- around IDNA -- I'm involved in, I gots to tell you that the IETF's imprimatur and a nickel will get you 5 cents worth of pennies, but only if the bank doesn't impose a service charge). > >>Perhaps instead you meant that there are not any > >>credible possibilities for NAT[v4-->v6]. ... > >>I think these are problems that can be solved, > >>and they would be solved faster in a working group. > > > >But so far, nobody has actually proposed anything that would solve > >them. > > Ouch. Perhaps I'm missing some draft, then. Hit me with the clue-stick, please. I'm almost always wrong about everything, so I'm prepared to be wrong here too. > > Instead, what we're getting is yet more spackle on top of > >patches like NAT64/DNS64. > > > Perhaps I am missing the point, but if an IPv4 host > wants to resolve the name of an IPv6-only host, isn't > DNS tautologically required to help out with that? Yes. And my claim is that this is a problem that absolutely nobody actually has, nor will have for some time to come. I would be astonished to learn otherwise. As soon as we get to the point where there is serious IPv6-only traffic, all the IPv4-only people will (1) get a real clue and go dual stack or (2) do (1) only with more invasive technology. If you're telling me that (2) can be done cleanly and in a well-standardized way, then please point me to the draft that doesn't include things like, "Except Skype is broken." Because we already have that with NAT64, and we're about to violate every sensible bone in my body forever in order to allow ourselves to detect that there's a DNS64 in the way. > > Hmmm... Just this morning, someone quoted Mark Townsley as > saying: > > "If you have something that solves 90% of a problem for 90% > of the population, you have a product to ship" Right. That's not the same as, "If you have something that solves 50% of a problem for 50% of the population, except that it breaks other things all over the network." Everything I've seen suggests to me that additional proposals fall into this category, IMO, but I'm totally prepared to be wrong. What draft have I missed? A -- Andrew Sullivan ajs@anvilwalrusden.com From simon.perreault@viagenie.ca Sat Aug 6 06:08: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 942B621F877D for ; Sat, 6 Aug 2011 06:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.385 X-Spam-Level: X-Spam-Status: No, score=-2.385 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Y9J5sl04KyE for ; Sat, 6 Aug 2011 06:08:36 -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 23C1121F8777 for ; Sat, 6 Aug 2011 06:08:36 -0700 (PDT) Received: from [192.168.1.49] (modemcable053.145-202-24.mc.videotron.ca [24.202.145.53]) by jazz.viagenie.ca (Postfix) with ESMTPSA id EB41821B94; Sat, 6 Aug 2011 09:08:55 -0400 (EDT) Message-ID: <4E3D3CE4.6080805@viagenie.ca> Date: Sat, 06 Aug 2011 09:08:52 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Dan Wing References: <4E3BDE80.500@viagenie.ca> <02b201cc53d0$2aa1c6d0$7fe55470$@com> <4E3C9693.1090200@viagenie.ca> <02c701cc53d9$16ecfb60$44c6f220$@com> In-Reply-To: <02c701cc53d9$16ecfb60$44c6f220$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: behave@ietf.org Subject: Re: [BEHAVE] [CGN reqs] Adjustments to logging section 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, 06 Aug 2011 13:08:36 -0000 Le 05/08/2011 9:35 PM, Dan Wing a écrit : >> Le 05/08/2011 8:31 PM, Dan Wing a écrit : >>> Much of the logging savings attributed to bulk port schemes is >> because >>> the destination isn't logged. >> >> I'm not following you. It's also possible to not log the destination >> with the traditional port allocation scheme, and bulk port allocation >> would still generate much fewer log entries. So I don't see how your >> proposed text is accurate. > > What you say is true. But I have never hard of anyone considering > bulk (source) port allocation combined with destination logging -- > there's no logging-related purpose (although there may well be > other purposes, but none of which have come up on the mailing list). Well, we're not talking exclusively about destination logging. We're talking about logging in general. Bulk port allocation generates fewer log entries, but you do need to use traditional allocation if you need destination logging. There's already a paragraph exclusively about this in the doc: Traditional allocation can log destinations while random and consecutive port sets cannot. This means that a CGN implementing one of the latter two will rely on the remote peer to follow the recommendations in [I-D.ietf-intarea-server-logging-recommendations]. If this is not acceptable, random or consecutive port sets cannot be used. Simon From jiangsheng@huawei.com Sun Aug 7 18:34: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 3D80621F8753 for ; Sun, 7 Aug 2011 18:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.017 X-Spam-Level: X-Spam-Status: No, score=-6.017 tagged_above=-999 required=5 tests=[AWL=0.582, 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 N4LyMOax-F0T for ; Sun, 7 Aug 2011 18:34:26 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE4A21F8751 for ; Sun, 7 Aug 2011 18:34:26 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPL00KIA5Q044@szxga05-in.huawei.com> for behave@ietf.org; Mon, 08 Aug 2011 09:34:49 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPL000795PZCX@szxga05-in.huawei.com> for behave@ietf.org; Mon, 08 Aug 2011 09:34:48 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml207-edg.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADB21318; Mon, 08 Aug 2011 09:34:46 +0800 (CST) Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 08 Aug 2011 09:34:45 +0800 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.17]) by szxeml408-hub.china.huawei.com ([169.254.27.188]) with mapi id 14.01.0270.001; Mon, 08 Aug 2011 09:34:47 +0800 Date: Mon, 08 Aug 2011 01:34:44 +0000 From: Jiangsheng In-reply-to: X-Originating-IP: [10.110.98.152] To: Ralph Droms , Brian E Carpenter Message-id: <5D36713D8A4E7348A7E10DF7437A4B92012282A2@SZXEML506-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-GB, zh-CN, en-US Thread-topic: [BEHAVE] Closing the behave WG Thread-index: AcxSOz1+np/vF0xnTkWaM1paeuvypwAOpfOAAAfSRQAAL8ukAAAGbpQAAAFFvQAAACj7gAB9ph0w X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <285AA91F41624C6B963A45FECC73F56E@davidPC> <4E3AEB4A.8080202@wichorus.com> <20110805174442.GR49271@shinkuro.com> <4E3C5734.6000009@wichorus.com> <4E3C5FBE.4090904@gmail.com> Cc: "Charles E. Perkins" , "behave@ietf.org" , Andrew Sullivan Subject: Re: [BEHAVE] Closing the behave WG 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, 08 Aug 2011 01:34:27 -0000 > Brian, et al., > > On Aug 5, 2011, at 5:25 PM 8/5/11, Brian E Carpenter wrote: > > > Charlie, > > > > On 2011-08-06 08:48, Charles E. Perkins wrote: > >> > >> Hello Andrew, > >> > >> On 8/5/2011 10:44 AM, Andrew Sullivan wrote: > >> > >>> On Thu, Aug 04, 2011 at 11:56:10AM -0700, Charles E. Perkins wrote: > >>> > >>>> I really think that NAT[v4-->v6] is important as > >>>> a perhaps crucial part of the transition story. > >>> > >>> I would like to see the argument for this. > >> > >> If we don't have NAT[v4-->v6], then IPv6-only > >> services are not going to be available to most > >> of the Internet for a really long time. > >> > >> Which, I reckon, means that all services are going > >> to be either IPv4-only or dual-stack for a really > >> long time. > > > > Correct. I've regarded that as a given for some years now. > > I wouldn't put any of my own money into an application service > > provider who proposed to go IPv6-only in the near future. > > > >> It seems to me that requiring all services to > >> have IPv4 addresses is directly counter to the > >> general IETF theme of promoting IPv6 transition. > > > > I try to avoid the word "transition" and focus on co-existence. > > Also, the "universal deployment of IPv6" does not imply > > "deployment of IPv6-only services". So I'm not sure that this > > is a current goal for the IETF. It seems like something that > > lies quite some years in the future. > > Seems to me, then, we can comfortably postpone serious work on NAT[v4-- > >v6] until (and if) we find we really need it... Fully agree. +1 In last year, we had some mobile providers told us they might have IPv6-only mobile devices. But now, the situation has changed. We are told all major mobile OSes support or plan to support, in short time scale, dual stack; and at their experimental measurement, running dual stack is not that computational consumption as they original thought. Without real traffic, keeping dual stack on is almost negligible. As long as there have no duplicated traffic for the same application, dual stack is not expensive than IPv4/Ipv6 single stack. So, the conclusion is even mobile devices would be dual stack. There won't be IPv6-only devices for a long while. Sheng > - Ralph > > > > > Regards > > > > Brian > > > >> Perhaps instead you meant that there are not any > >> credible possibilities for NAT[v4-->v6]. I am > >> willing to agree that as far as I understand it > >> the alternatives (as of now) have problems of either > >> scalability or maybe vulnerability to DoS attacks. > >> I think these are problems that can be solved, > >> and they would be solved faster in a working group. > >> > >> Looked at another way, if [behave] shuts down > >> without working on NAT[v4-->v6], then it can be > >> seen as sending a strong message that the IETF > >> believes that all services and websites really need > >> to maintain IPv4 addressability ad infinitum > >> [or at least all commercially viable ones]. > >> > >> Regards, > >> Charlie P. > >> > >> _______________________________________________ > >> 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 > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From cb.list6@gmail.com Sun Aug 7 18:53: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 6842621F86BE for ; Sun, 7 Aug 2011 18:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.44 X-Spam-Level: X-Spam-Status: No, score=-3.44 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 FObDqkjwpMK5 for ; Sun, 7 Aug 2011 18:53:50 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 168BE21F86BD for ; Sun, 7 Aug 2011 18:53:49 -0700 (PDT) Received: by wyg8 with SMTP id 8so2587248wyg.31 for ; Sun, 07 Aug 2011 18:54:14 -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; bh=OL0dL5e/B0KH5jsALDj7RqpqJTnQngkUkMQirFGEeV0=; b=mLXBRoClwUNXRNWrfbVCupnFeYX6ei82sHyEyY2GMNHzlNbKw8NuVOpjFD4l5mmXUh n62WBnITdbO8T8yRCoc0mOfSdR8JoctUqTP2CBHOq5eDoMmQfNKcun7blu6pbrhBZ+TY dCOljHDoEdoLRiubUm3mIdL9Lp5HZpkm5nF6s= MIME-Version: 1.0 Received: by 10.216.176.17 with SMTP id a17mr1221408wem.72.1312768454084; Sun, 07 Aug 2011 18:54:14 -0700 (PDT) Received: by 10.216.177.213 with HTTP; Sun, 7 Aug 2011 18:54:13 -0700 (PDT) Received: by 10.216.177.213 with HTTP; Sun, 7 Aug 2011 18:54:13 -0700 (PDT) In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B92012282A2@SZXEML506-MBS.china.huawei.com> References: <285AA91F41624C6B963A45FECC73F56E@davidPC> <4E3AEB4A.8080202@wichorus.com> <20110805174442.GR49271@shinkuro.com> <4E3C5734.6000009@wichorus.com> <4E3C5FBE.4090904@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B92012282A2@SZXEML506-MBS.china.huawei.com> Date: Sun, 7 Aug 2011 18:54:13 -0700 Message-ID: From: Cameron Byrne To: Jiangsheng Content-Type: multipart/alternative; boundary=0016e65c7ca460c9ea04a9f4b952 Cc: "Charles E. Perkins" , "behave@ietf.org" , Andrew Sullivan , Ralph Droms Subject: Re: [BEHAVE] Closing the behave WG 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, 08 Aug 2011 01:53:51 -0000 --0016e65c7ca460c9ea04a9f4b952 Content-Type: text/plain; charset=ISO-8859-1 On Aug 7, 2011 6:35 PM, "Jiangsheng" wrote: > > > Brian, et al., > > > > On Aug 5, 2011, at 5:25 PM 8/5/11, Brian E Carpenter wrote: > > > > > Charlie, > > > > > > On 2011-08-06 08:48, Charles E. Perkins wrote: > > >> > > >> Hello Andrew, > > >> > > >> On 8/5/2011 10:44 AM, Andrew Sullivan wrote: > > >> > > >>> On Thu, Aug 04, 2011 at 11:56:10AM -0700, Charles E. Perkins wrote: > > >>> > > >>>> I really think that NAT[v4-->v6] is important as > > >>>> a perhaps crucial part of the transition story. > > >>> > > >>> I would like to see the argument for this. > > >> > > >> If we don't have NAT[v4-->v6], then IPv6-only > > >> services are not going to be available to most > > >> of the Internet for a really long time. > > >> > > >> Which, I reckon, means that all services are going > > >> to be either IPv4-only or dual-stack for a really > > >> long time. > > > > > > Correct. I've regarded that as a given for some years now. > > > I wouldn't put any of my own money into an application service > > > provider who proposed to go IPv6-only in the near future. > > > > > >> It seems to me that requiring all services to > > >> have IPv4 addresses is directly counter to the > > >> general IETF theme of promoting IPv6 transition. > > > > > > I try to avoid the word "transition" and focus on co-existence. > > > Also, the "universal deployment of IPv6" does not imply > > > "deployment of IPv6-only services". So I'm not sure that this > > > is a current goal for the IETF. It seems like something that > > > lies quite some years in the future. > > > > Seems to me, then, we can comfortably postpone serious work on NAT[v4-- > > >v6] until (and if) we find we really need it... > > Fully agree. +1 > > In last year, we had some mobile providers told us they might have IPv6-only mobile devices. But now, the situation has changed. We are told all major mobile OSes support or plan to support, in short time scale, dual stack; and at their experimental measurement, running dual stack is not that computational consumption as they original thought. Without real traffic, keeping dual stack on is almost negligible. As long as there have no duplicated traffic for the same application, dual stack is not expensive than IPv4/Ipv6 single stack. So, the conclusion is even mobile devices would be dual stack. There won't be IPv6-only devices for a long while. > My understanding is different. In fact, I am a mobile operator that has beta ipv6-only capable devices that will be launched soon. Furthermore, dual-stack in pre-release 9 networks is 2x the pdp , which generally translates to 2x the cost (lincenses, signalling, mobility events, session setup, authetication...). This case is different in LTE, but the LTE ramp rate is still very very small compared to gsm and umts.... and dual stack fundamentally does not solve private and public address exhaustion that most mobile providers are currently challenged with, since dual stack requires the ipv4 address that are ....exhausted.... so if ipv4 exhaustion is a tactical business problem, dual stack is not the answer... and yes, the devices are in the pipeline Cb > Sheng > > > - Ralph > > > > > > > > Regards > > > > > > Brian > > > > > >> Perhaps instead you meant that there are not any > > >> credible possibilities for NAT[v4-->v6]. I am > > >> willing to agree that as far as I understand it > > >> the alternatives (as of now) have problems of either > > >> scalability or maybe vulnerability to DoS attacks. > > >> I think these are problems that can be solved, > > >> and they would be solved faster in a working group. > > >> > > >> Looked at another way, if [behave] shuts down > > >> without working on NAT[v4-->v6], then it can be > > >> seen as sending a strong message that the IETF > > >> believes that all services and websites really need > > >> to maintain IPv4 addressability ad infinitum > > >> [or at least all commercially viable ones]. > > >> > > >> Regards, > > >> Charlie P. > > >> > > >> _______________________________________________ > > >> 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 > > > > _______________________________________________ > > 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 --0016e65c7ca460c9ea04a9f4b952 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Aug 7, 2011 6:35 PM, "Jiangsheng" <jiangsheng@huawei.com> wrote:
>
> > Brian, et al.,
> >
> > On Aug 5, 2011, at 5:25 PM 8/5/11, Brian E Carpenter wrote:
> >
> > > Charlie,
> > >
> > > On 2011-08-06 08:48, Charles E. Perkins wrote:
> > >>
> > >> Hello Andrew,
> > >>
> > >> On 8/5/2011 10:44 AM, Andrew Sullivan wrote:
> > >>
> > >>> On Thu, Aug 04, 2011 at 11:56:10AM -0700, Charles E.= Perkins wrote:
> > >>>
> > >>>> I really think that NAT[v4-->v6] is important= as
> > >>>> a perhaps crucial part of the transition story.<= br> > > >>>
> > >>> I would like to see the argument for this.
> > >>
> > >> If we don't have NAT[v4-->v6], then IPv6-only
> > >> services are not going to be available to most
> > >> of the Internet for a really long time.
> > >>
> > >> Which, I reckon, means that all services are going
> > >> to be either IPv4-only or dual-stack for a really
> > >> long time.
> > >
> > > Correct. I've regarded that as a given for some years no= w.
> > > I wouldn't put any of my own money into an application s= ervice
> > > provider who proposed to go IPv6-only in the near future. > > >
> > >> It seems to me that requiring all services to
> > >> have IPv4 addresses is directly counter to the
> > >> general IETF theme of promoting IPv6 transition.
> > >
> > > I try to avoid the word "transition" and focus on = co-existence.
> > > Also, the "universal deployment of IPv6" does not = imply
> > > "deployment of IPv6-only services". So I'm not= sure that this
> > > is a current goal for the IETF. It seems like something that=
> > > lies quite some years in the future.
> >
> > Seems to me, then, we can comfortably postpone serious work on NA= T[v4--
> > >v6] until (and if) we find we really need it...
>
> Fully agree. +1
>
> In last year, we had some mobile providers told us they might have IPv= 6-only mobile devices. But now, the situation has changed. We are told all = major mobile OSes support or plan to support, in short time scale, dual sta= ck; and at their experimental measurement, running dual stack is not that c= omputational consumption as they original thought. Without real traffic, ke= eping dual stack on is almost negligible. As long as there have no duplicat= ed traffic for the same application, dual stack is not expensive than IPv4/= Ipv6 single stack. So, the conclusion is even mobile devices would be dual = stack. There won't be IPv6-only devices for a long while.
>

My understanding is different.

In fact, I am a mobile operator that has beta ipv6-only capable devices = that will be launched soon.

Furthermore, dual-stack in pre-release 9 networks is 2x the pdp , which = generally translates to 2x the cost (lincenses, signalling, mobility events= , session setup, authetication...). This case is different in LTE, but the = LTE ramp rate is still very very small compared to gsm and umts.... and dua= l stack fundamentally does not solve private and public address exhaustion = that most mobile providers are currently challenged with, since dual stack = requires the ipv4 address that are ....exhausted.... so if ipv4 exhaustion = is a tactical business problem, dual stack is not the answer... and yes, th= e devices are in the pipeline

Cb

> Sheng
>
> > - Ralph
> >
> > >
> > > Regards
> > >
> > > =A0 Brian
> > >
> > >> Perhaps instead you meant that there are not any
> > >> credible possibilities for NAT[v4-->v6]. =A0I am
> > >> willing to agree that as far as I understand it
> > >> the alternatives (as of now) have problems of either
> > >> scalability or maybe vulnerability to DoS attacks.
> > >> I think these are problems that can be solved,
> > >> and they would be solved faster in a working group.
> > >>
> > >> Looked at another way, if [behave] shuts down
> > >> without working on NAT[v4-->v6], then it can be
> > >> seen as sending a strong message that the IETF
> > >> believes that all services and websites really need
> > >> to maintain IPv4 addressability ad infinitum
> > >> [or at least all commercially viable ones].
> > >>
> > >> Regards,
> > >> Charlie P.
> > >>
> > >> _______________________________________________
> > >> Behave mailing list
> > >> Behave@ietf.org > > >> https://www.ietf.org/mailman/listinfo/behave
> > >>
> > > _______________________________________________
> > > Behave mailing list
> > > Behave@ietf.org
> > > htt= ps://www.ietf.org/mailman/listinfo/behave
> >
> > _______________________________________________
> > Behave mailing list
> > Behave@ietf.org
> > https://= www.ietf.org/mailman/listinfo/behave
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.i= etf.org/mailman/listinfo/behave

--0016e65c7ca460c9ea04a9f4b952-- From jiangsheng@huawei.com Sun Aug 7 18:58: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 6869C21F87C7 for ; Sun, 7 Aug 2011 18:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.036 X-Spam-Level: X-Spam-Status: No, score=-6.036 tagged_above=-999 required=5 tests=[AWL=0.562, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 M2IAFsstxgO1 for ; Sun, 7 Aug 2011 18:58:32 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id E5ADC21F8751 for ; Sun, 7 Aug 2011 18:58:31 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPL0048R6U63X@szxga03-in.huawei.com> for behave@ietf.org; Mon, 08 Aug 2011 09:58:54 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPL006RD6U4R7@szxga03-in.huawei.com> for behave@ietf.org; Mon, 08 Aug 2011 09:58:54 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml201-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACZ25045; Mon, 08 Aug 2011 09:58:53 +0800 (CST) Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 08 Aug 2011 09:58:52 +0800 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.17]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0270.001; Mon, 08 Aug 2011 09:58:54 +0800 Date: Mon, 08 Aug 2011 01:58:51 +0000 From: Jiangsheng In-reply-to: X-Originating-IP: [10.110.98.152] To: Cameron Byrne Message-id: <5D36713D8A4E7348A7E10DF7437A4B9201228313@SZXEML506-MBS.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_VrmPCMd/lmHttkqHoPXmIQ)" Content-language: zh-CN Accept-Language: en-GB, zh-CN, en-US Thread-topic: [BEHAVE] Closing the behave WG Thread-index: AcxSOz1+np/vF0xnTkWaM1paeuvypwAOpfOAAAfSRQAAL8ukAAAGbpQAAAFFvQAAACj7gAB9ph0w//+BU4D//3j4gA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <285AA91F41624C6B963A45FECC73F56E@davidPC> <4E3AEB4A.8080202@wichorus.com> <20110805174442.GR49271@shinkuro.com> <4E3C5734.6000009@wichorus.com> <4E3C5FBE.4090904@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B92012282A2@SZXEML506-MBS.china.huawei.com> Cc: "Charles E. Perkins" , "behave@ietf.org" , Ralph Droms , Andrew Sullivan Subject: Re: [BEHAVE] Closing the behave WG 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, 08 Aug 2011 01:58:33 -0000 --Boundary_(ID_VrmPCMd/lmHttkqHoPXmIQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of Cameron Byrne Sent: Monday, August 08, 2011 9:54 AM To: Jiangsheng Cc: Charles E. Perkins; behave@ietf.org; Andrew Sullivan; Ralph Droms Subject: Re: [BEHAVE] Closing the behave WG On Aug 7, 2011 6:35 PM, "Jiangsheng" > wrote: > > > Brian, et al., > > > > On Aug 5, 2011, at 5:25 PM 8/5/11, Brian E Carpenter wrote: > > > > > Charlie, > > > > > > On 2011-08-06 08:48, Charles E. Perkins wrote: > > >> > > >> Hello Andrew, > > >> > > >> On 8/5/2011 10:44 AM, Andrew Sullivan wrote: > > >> > > >>> On Thu, Aug 04, 2011 at 11:56:10AM -0700, Charles E. Perkins wrote: > > >>> > > >>>> I really think that NAT[v4-->v6] is important as > > >>>> a perhaps crucial part of the transition story. > > >>> > > >>> I would like to see the argument for this. > > >> > > >> If we don't have NAT[v4-->v6], then IPv6-only > > >> services are not going to be available to most > > >> of the Internet for a really long time. > > >> > > >> Which, I reckon, means that all services are going > > >> to be either IPv4-only or dual-stack for a really > > >> long time. > > > > > > Correct. I've regarded that as a given for some years now. > > > I wouldn't put any of my own money into an application service > > > provider who proposed to go IPv6-only in the near future. > > > > > >> It seems to me that requiring all services to > > >> have IPv4 addresses is directly counter to the > > >> general IETF theme of promoting IPv6 transition. > > > > > > I try to avoid the word "transition" and focus on co-existence. > > > Also, the "universal deployment of IPv6" does not imply > > > "deployment of IPv6-only services". So I'm not sure that this > > > is a current goal for the IETF. It seems like something that > > > lies quite some years in the future. > > > > Seems to me, then, we can comfortably postpone serious work on NAT[v4-- > > >v6] until (and if) we find we really need it... > > Fully agree. +1 > > In last year, we had some mobile providers told us they might have IPv6-only mobile devices. But now, the situation has changed. We are told all major mobile OSes support or plan to support, in short time scale, dual stack; and at their experimental measurement, running dual stack is not that computational consumption as they original thought. Without real traffic, keeping dual stack on is almost negligible. As long as there have no duplicated traffic for the same application, dual stack is not expensive than IPv4/Ipv6 single stack. So, the conclusion is even mobile devices would be dual stack. There won't be IPv6-only devices for a long while. > My understanding is different. In fact, I am a mobile operator that has beta ipv6-only capable devices that will be launched soon. Furthermore, dual-stack in pre-release 9 networks is 2x the pdp , which generally translates to 2x the cost (lincenses, signalling, mobility events, session setup, authetication...). This case is different in LTE, but the LTE ramp rate is still very very small compared to gsm and umts.... and dual stack fundamentally does not solve private and public address exhaustion that most mobile providers are currently challenged with, since dual stack requires the ipv4 address that are ....exhausted.... so if ipv4 exhaustion is a tactical business problem, dual stack is not the answer... and yes, the devices are in the pipeline Cb > Sheng > > > - Ralph > > > > > > > > Regards > > > > > > Brian > > > > > >> Perhaps instead you meant that there are not any > > >> credible possibilities for NAT[v4-->v6]. I am > > >> willing to agree that as far as I understand it > > >> the alternatives (as of now) have problems of either > > >> scalability or maybe vulnerability to DoS attacks. > > >> I think these are problems that can be solved, > > >> and they would be solved faster in a working group. > > >> > > >> Looked at another way, if [behave] shuts down > > >> without working on NAT[v4-->v6], then it can be > > >> seen as sending a strong message that the IETF > > >> believes that all services and websites really need > > >> to maintain IPv4 addressability ad infinitum > > >> [or at least all commercially viable ones]. > > >> > > >> Regards, > > >> Charlie P. > > >> > > >> _______________________________________________ > > >> 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 > > > > _______________________________________________ > > 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 --Boundary_(ID_VrmPCMd/lmHttkqHoPXmIQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

 

 

From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of Cameron Byrne
Sent: Monday, August 08, 2011 9:54 AM
To: Jiangsheng
Cc: Charles E. Perkins; behave@ietf.org; Andrew Sullivan; Ralph Droms
Subject: Re: [BEHAVE] Closing the behave WG

 


On Aug 7, 2011 6:35 PM, "Jiangsheng" <jiangsheng@huawei.com> wrote:
>
> > Brian, et al.,
> >
> > On Aug 5, 2011, at 5:25 PM 8/5/11, Brian E Carpenter wrote:
> >
> > > Charlie,
> > >
> > > On 2011-08-06 08:48, Charles E. Perkins wrote:
> > >>
> > >> Hello Andrew,
> > >>
> > >> On 8/5/2011 10:44 AM, Andrew Sullivan wrote:
> > >>
> > >>> On Thu, Aug 04, 2011 at 11:56:10AM -0700, Charles E. Perkins wrote:
> > >>>
> > >>>> I really think that NAT[v4-->v6] is important as
> > >>>> a perhaps crucial part of the transition story.
> > >>>
> > >>> I would like to see the argument for this.
> > >>
> > >> If we don't have NAT[v4-->v6], then IPv6-only
> > >> services are not going to be available to most
> > >> of the Internet for a really long time.
> > >>
> > >> Which, I reckon, means that all services are going
> > >> to be either IPv4-only or dual-stack for a really
> > >> long time.
> > >
> > > Correct. I've regarded that as a given for some years now.
> > > I wouldn't put any of my own money into an application service
> > > provider who proposed to go IPv6-only in the near future.
> > >
> > >> It seems to me that requiring all services to
> > >> have IPv4 addresses is directly counter to the
> > >> general IETF theme of promoting IPv6 transition.
> > >
> > > I try to avoid the word "transition" and focus on co-existence.
> > > Also, the "universal deployment of IPv6" does not imply
> > > "deployment of IPv6-only services". So I'm not sure that this
> > > is a current goal for the IETF. It seems like something that
> > > lies quite some years in the future.
> >
> > Seems to me, then, we can comfortably postpone serious work on NAT[v4--
> > >v6] until (and if) we find we really need it...
>
> Fully agree. +1
>
> In last year, we had some mobile providers told us they might have IPv6-only mobile devices. But now, the situation has changed. We are told all major mobile OSes support or plan to support, in short time scale, dual stack; and at their experimental measurement, running dual stack is not that computational consumption as they original thought. Without real traffic, keeping dual stack on is almost negligible. As long as there have no duplicated traffic for the same application, dual stack is not expensive than IPv4/Ipv6 single stack. So, the conclusion is even mobile devices would be dual stack. There won't be IPv6-only devices for a long while.
>

My understanding is different.

In fact, I am a mobile operator that has beta ipv6-only capable devices that will be launched soon.

Furthermore, dual-stack in pre-release 9 networks is 2x the pdp , which generally translates to 2x the cost (lincenses, signalling, mobility events, session setup, authetication...). This case is different in LTE, but the LTE ramp rate is still very very small compared to gsm and umts.... and dual stack fundamentally does not solve private and public address exhaustion that most mobile providers are currently challenged with, since dual stack requires the ipv4 address that are ....exhausted.... so if ipv4 exhaustion is a tactical business problem, dual stack is not the answer... and yes, the devices are in the pipeline

Cb

> Sheng
>
> > - Ralph
> >
> > >
> > > Regards
> > >
> > >   Brian
> > >
> > >> Perhaps instead you meant that there are not any
> > >> credible possibilities for NAT[v4-->v6].  I am
> > >> willing to agree that as far as I understand it
> > >> the alternatives (as of now) have problems of either
> > >> scalability or maybe vulnerability to DoS attacks.
> > >> I think these are problems that can be solved,
> > >> and they would be solved faster in a working group.
> > >>
> > >> Looked at another way, if [behave] shuts down
> > >> without working on NAT[v4-->v6], then it can be
> > >> seen as sending a strong message that the IETF
> > >> believes that all services and websites really need
> > >> to maintain IPv4 addressability ad infinitum
> > >> [or at least all commercially viable ones].
> > >>
> > >> Regards,
> > >> Charlie P.
> > >>
> > >> _______________________________________________
> > >> 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
> >
> > _______________________________________________
> > 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

--Boundary_(ID_VrmPCMd/lmHttkqHoPXmIQ)-- From jiangsheng@huawei.com Sun Aug 7 19:08:24 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ABC121F8753 for ; Sun, 7 Aug 2011 19:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.055 X-Spam-Level: X-Spam-Status: No, score=-6.055 tagged_above=-999 required=5 tests=[AWL=0.543, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Acd6cBb6EoyA for ; Sun, 7 Aug 2011 19:08:21 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 8020A21F874C for ; Sun, 7 Aug 2011 19:08:16 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPL00KZN7AF44@szxga05-in.huawei.com> for behave@ietf.org; Mon, 08 Aug 2011 10:08:39 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPL002JG7AEIM@szxga05-in.huawei.com> for behave@ietf.org; Mon, 08 Aug 2011 10:08:39 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml208-edg.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADB22950; Mon, 08 Aug 2011 10:08:37 +0800 (CST) Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 08 Aug 2011 10:08:36 +0800 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.17]) by szxeml404-hub.china.huawei.com ([fe80::75b7:3db9:fedc:a56d%13]) with mapi id 14.01.0270.001; Mon, 08 Aug 2011 10:08:36 +0800 Date: Mon, 08 Aug 2011 02:08:35 +0000 From: Jiangsheng In-reply-to: X-Originating-IP: [10.110.98.152] To: Cameron Byrne Message-id: <5D36713D8A4E7348A7E10DF7437A4B9201228345@SZXEML506-MBS.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_tujUh4nuyPvYP3ivrOlOzA)" Content-language: zh-CN Accept-Language: en-GB, zh-CN, en-US Thread-topic: [BEHAVE] Closing the behave WG Thread-index: AcxSOz1+np/vF0xnTkWaM1paeuvypwAOpfOAAAfSRQAAL8ukAAAGbpQAAAFFvQAAACj7gAB9ph0w//+BU4D//3iRwA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <285AA91F41624C6B963A45FECC73F56E@davidPC> <4E3AEB4A.8080202@wichorus.com> <20110805174442.GR49271@shinkuro.com> <4E3C5734.6000009@wichorus.com> <4E3C5FBE.4090904@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B92012282A2@SZXEML506-MBS.china.huawei.com> Cc: "Charles E. Perkins" , "behave@ietf.org" , Ralph Droms , Andrew Sullivan Subject: Re: [BEHAVE] Closing the behave WG 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, 08 Aug 2011 02:08:24 -0000 --Boundary_(ID_tujUh4nuyPvYP3ivrOlOzA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Oops... The previous email was sent with any information by wrong button. From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of Cameron Byrne Sent: Monday, August 08, 2011 9:54 AM To: Jiangsheng Cc: Charles E. Perkins; behave@ietf.org; Andrew Sullivan; Ralph Droms Subject: Re: [BEHAVE] Closing the behave WG On Aug 7, 2011 6:35 PM, "Jiangsheng" > wrote: > > > Brian, et al., > > > > On Aug 5, 2011, at 5:25 PM 8/5/11, Brian E Carpenter wrote: > > > > > Charlie, > > > > > > On 2011-08-06 08:48, Charles E. Perkins wrote: > > >> > > >> Hello Andrew, > > >> > > >> On 8/5/2011 10:44 AM, Andrew Sullivan wrote: > > >> > > >>> On Thu, Aug 04, 2011 at 11:56:10AM -0700, Charles E. Perkins wrote: > > >>> > > >>>> I really think that NAT[v4-->v6] is important as > > >>>> a perhaps crucial part of the transition story. > > >>> > > >>> I would like to see the argument for this. > > >> > > >> If we don't have NAT[v4-->v6], then IPv6-only > > >> services are not going to be available to most > > >> of the Internet for a really long time. > > >> > > >> Which, I reckon, means that all services are going > > >> to be either IPv4-only or dual-stack for a really > > >> long time. > > > > > > Correct. I've regarded that as a given for some years now. > > > I wouldn't put any of my own money into an application service > > > provider who proposed to go IPv6-only in the near future. > > > > > >> It seems to me that requiring all services to > > >> have IPv4 addresses is directly counter to the > > >> general IETF theme of promoting IPv6 transition. > > > > > > I try to avoid the word "transition" and focus on co-existence. > > > Also, the "universal deployment of IPv6" does not imply > > > "deployment of IPv6-only services". So I'm not sure that this > > > is a current goal for the IETF. It seems like something that > > > lies quite some years in the future. > > > > Seems to me, then, we can comfortably postpone serious work on NAT[v4-- > > >v6] until (and if) we find we really need it... > > Fully agree. +1 > > In last year, we had some mobile providers told us they might have IPv6-only mobile devices. But now, the situation has changed. We are told all major mobile OSes support or plan to support, in short time scale, dual stack; and at their experimental measurement, running dual stack is not that computational consumption as they original thought. Without real traffic, keeping dual stack on is almost negligible. As long as there have no duplicated traffic for the same application, dual stack is not expensive than IPv4/Ipv6 single stack. So, the conclusion is even mobile devices would be dual stack. There won't be IPv6-only devices for a long while. > My understanding is different. In fact, I am a mobile operator that has beta ipv6-only capable devices that will be launched soon. Yes, we have mobile operator customers who are strategically choose IPv6-only network + Nat64. What I said above is the information I got from Handset devices perspective. Furthermore, dual-stack in pre-release 9 networks is 2x the pdp , which generally translates to 2x the cost (lincenses, signalling, mobility events, session setup, authetication...). These cost may not necessary for the handset devices depends on how mobile provider operates the network. These abovementioned operational cost can be handled by layer 2. Then, in layer 3, dual stack has almost the same cost with single IPv4/IPv6 stack. This case is different in LTE, but the LTE ramp rate is still very very small compared to gsm and umts.... and dual stack fundamentally does not solve private and public address exhaustion that most mobile providers are currently challenged with, since dual stack requires the ipv4 address that are ....exhausted.... so if ipv4 exhaustion is a tactical business problem, dual stack is not the answer... and yes, the devices are in the pipeline From last year, when we say dual stack, we do NOT mean IPv6 + public IPv4. It can be IPv6 + private IPv4, too. This may request more operational cost at network provider for CGN. But from handset perspective, they do not care IPv4 private or public address, unless there are considerable performance different. Sheng Cb > Sheng > > > - Ralph > > > > > > > > Regards > > > > > > Brian > > > > > >> Perhaps instead you meant that there are not any > > >> credible possibilities for NAT[v4-->v6]. I am > > >> willing to agree that as far as I understand it > > >> the alternatives (as of now) have problems of either > > >> scalability or maybe vulnerability to DoS attacks. > > >> I think these are problems that can be solved, > > >> and they would be solved faster in a working group. > > >> > > >> Looked at another way, if [behave] shuts down > > >> without working on NAT[v4-->v6], then it can be > > >> seen as sending a strong message that the IETF > > >> believes that all services and websites really need > > >> to maintain IPv4 addressability ad infinitum > > >> [or at least all commercially viable ones]. > > >> > > >> Regards, > > >> Charlie P. > > >> > > >> _______________________________________________ > > >> 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 > > > > _______________________________________________ > > 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 --Boundary_(ID_tujUh4nuyPvYP3ivrOlOzA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Oops… The previous email was sent with any information by wrong button.

 

From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of Cameron Byrne
Sent: Monday, August 08, 2011 9:54 AM
To: Jiangsheng
Cc: Charles E. Perkins; behave@ietf.org; Andrew Sullivan; Ralph Droms
Subject: Re: [BEHAVE] Closing the behave WG

 


On Aug 7, 2011 6:35 PM, "Jiangsheng" <jiangsheng@huawei.com> wrote:
>
> > Brian, et al.,
> >
> > On Aug 5, 2011, at 5:25 PM 8/5/11, Brian E Carpenter wrote:
> >
> > > Charlie,
> > >
> > > On 2011-08-06 08:48, Charles E. Perkins wrote:
> > >>
> > >> Hello Andrew,
> > >>
> > >> On 8/5/2011 10:44 AM, Andrew Sullivan wrote:
> > >>
> > >>> On Thu, Aug 04, 2011 at 11:56:10AM -0700, Charles E. Perkins wrote:
> > >>>
> > >>>> I really think that NAT[v4-->v6] is important as
> > >>>> a perhaps crucial part of the transition story.
> > >>>
> > >>> I would like to see the argument for this.
> > >>
> > >> If we don't have NAT[v4-->v6], then IPv6-only
> > >> services are not going to be available to most
> > >> of the Internet for a really long time.
> > >>
> > >> Which, I reckon, means that all services are going
> > >> to be either IPv4-only or dual-stack for a really
> > >> long time.
> > >
> > > Correct. I've regarded that as a given for some years now.
> > > I wouldn't put any of my own money into an application service
> > > provider who proposed to go IPv6-only in the near future.
> > >
> > >> It seems to me that requiring all services to
> > >> have IPv4 addresses is directly counter to the
> > >> general IETF theme of promoting IPv6 transition.
> > >
> > > I try to avoid the word "transition" and focus on co-existence.
> > > Also, the "universal deployment of IPv6" does not imply
> > > "deployment of IPv6-only services". So I'm not sure that this
> > > is a current goal for the IETF. It seems like something that
> > > lies quite some years in the future.
> >
> > Seems to me, then, we can comfortably postpone serious work on NAT[v4--
> > >v6] until (and if) we find we really need it...
>
> Fully agree. +1
>
> In last year, we had some mobile providers told us they might have IPv6-only mobile devices. But now, the situation has changed. We are told all major mobile OSes support or plan to support, in short time scale, dual stack; and at their experimental measurement, running dual stack is not that computational consumption as they original thought. Without real traffic, keeping dual stack on is almost negligible. As long as there have no duplicated traffic for the same application, dual stack is not expensive than IPv4/Ipv6 single stack. So, the conclusion is even mobile devices would be dual stack. There won't be IPv6-only devices for a long while.
>

My understanding is different.

In fact, I am a mobile operator that has beta ipv6-only capable devices that will be launched soon.

<Sheng> Yes, we have mobile operator customers who are strategically choose IPv6-only network + Nat64. What I said above is the information I got from Handset devices perspective.

Furthermore, dual-stack in pre-release 9 networks is 2x the pdp , which generally translates to 2x the cost (lincenses, signalling, mobility events, session setup, authetication...).

<Sheng> These cost may not necessary for the handset devices depends on how mobile provider operates the network. These abovementioned operational cost can be handled by layer 2. Then, in layer 3, dual stack has almost the same cost with single IPv4/IPv6 stack.

This case is different in LTE, but the LTE ramp rate is still very very small compared to gsm and umts....

and dual stack fundamentally does not solve private and public address exhaustion that most mobile providers are currently challenged with, since dual stack requires the ipv4 address that are ....exhausted.... so if ipv4 exhaustion is a tactical business problem, dual stack is not the answer... and yes, the devices are in the pipeline

<Sheng> From last year, when we say dual stack, we do NOT mean IPv6 + public IPv4. It can be IPv6 + private IPv4, too. This may request more operational cost at network provider for CGN. But from handset perspective, they do not care IPv4 private or public address, unless there are considerable performance different.

Sheng

Cb

> Sheng
>
> > - Ralph
> >
> > >
> > > Regards
> > >
> > >   Brian
> > >
> > >> Perhaps instead you meant that there are not any
> > >> credible possibilities for NAT[v4-->v6].  I am
> > >> willing to agree that as far as I understand it
> > >> the alternatives (as of now) have problems of either
> > >> scalability or maybe vulnerability to DoS attacks.
> > >> I think these are problems that can be solved,
> > >> and they would be solved faster in a working group.
> > >>
> > >> Looked at another way, if [behave] shuts down
> > >> without working on NAT[v4-->v6], then it can be
> > >> seen as sending a strong message that the IETF
> > >> believes that all services and websites really need
> > >> to maintain IPv4 addressability ad infinitum
> > >> [or at least all commercially viable ones].
> > >>
> > >> Regards,
> > >> Charlie P.
> > >>
> > >> _______________________________________________
> > >> 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
> >
> > _______________________________________________
> > 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

--Boundary_(ID_tujUh4nuyPvYP3ivrOlOzA)-- From cb.list6@gmail.com Sun Aug 7 20:07: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 28D4121F8869 for ; Sun, 7 Aug 2011 20:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.444 X-Spam-Level: X-Spam-Status: No, score=-3.444 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 lhvSe7DGG+eJ for ; Sun, 7 Aug 2011 20:07:42 -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 4033021F8866 for ; Sun, 7 Aug 2011 20:07:42 -0700 (PDT) Received: by wwf5 with SMTP id 5so823640wwf.13 for ; Sun, 07 Aug 2011 20:08:06 -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; bh=lhu4sDe42XILLLJ7lnjq4SOBOXoBsquM6pFhGTQJ8iQ=; b=n5xi1brMDG8qep2qs2ZGaf4cI4G6g0LtKEZcQkF3m6lRLSA9Kp6DGUTna578jw0uKM dQdZhunj3CdS5hnD4E1Z43f9j4KHy/+zqk7v0AmyHbB9RdZpk35jEbqI9VZbXopbA8to WkcLyi2IiKVaKmiAT5s2AkfeY7IYMOEsLmrLw= MIME-Version: 1.0 Received: by 10.216.233.95 with SMTP id o73mr2649560weq.103.1312772879693; Sun, 07 Aug 2011 20:07:59 -0700 (PDT) Received: by 10.216.177.213 with HTTP; Sun, 7 Aug 2011 20:07:59 -0700 (PDT) Received: by 10.216.177.213 with HTTP; Sun, 7 Aug 2011 20:07:59 -0700 (PDT) In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B9201228345@SZXEML506-MBS.china.huawei.com> References: <285AA91F41624C6B963A45FECC73F56E@davidPC> <4E3AEB4A.8080202@wichorus.com> <20110805174442.GR49271@shinkuro.com> <4E3C5734.6000009@wichorus.com> <4E3C5FBE.4090904@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B92012282A2@SZXEML506-MBS.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B9201228345@SZXEML506-MBS.china.huawei.com> Date: Sun, 7 Aug 2011 20:07:59 -0700 Message-ID: From: Cameron Byrne To: Jiangsheng Content-Type: multipart/alternative; boundary=000e0cd4841a2a390504a9f5c12a Cc: "Charles E. Perkins" , "behave@ietf.org" , Ralph Droms , Andrew Sullivan Subject: Re: [BEHAVE] Closing the behave WG 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, 08 Aug 2011 03:07:44 -0000 --000e0cd4841a2a390504a9f5c12a Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Aug 7, 2011 7:09 PM, "Jiangsheng" wrote: > > Oops=85 The previous email was sent with any information by wrong button. > > > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of Cameron Byrne > Sent: Monday, August 08, 2011 9:54 AM > To: Jiangsheng > Cc: Charles E. Perkins; behave@ietf.org; Andrew Sullivan; Ralph Droms > Subject: Re: [BEHAVE] Closing the behave WG > > > > > On Aug 7, 2011 6:35 PM, "Jiangsheng" wrote: > > > > > Brian, et al., > > > > > > On Aug 5, 2011, at 5:25 PM 8/5/11, Brian E Carpenter wrote: > > > > > > > Charlie, > > > > > > > > On 2011-08-06 08:48, Charles E. Perkins wrote: > > > >> > > > >> Hello Andrew, > > > >> > > > >> On 8/5/2011 10:44 AM, Andrew Sullivan wrote: > > > >> > > > >>> On Thu, Aug 04, 2011 at 11:56:10AM -0700, Charles E. Perkins wrote: > > > >>> > > > >>>> I really think that NAT[v4-->v6] is important as > > > >>>> a perhaps crucial part of the transition story. > > > >>> > > > >>> I would like to see the argument for this. > > > >> > > > >> If we don't have NAT[v4-->v6], then IPv6-only > > > >> services are not going to be available to most > > > >> of the Internet for a really long time. > > > >> > > > >> Which, I reckon, means that all services are going > > > >> to be either IPv4-only or dual-stack for a really > > > >> long time. > > > > > > > > Correct. I've regarded that as a given for some years now. > > > > I wouldn't put any of my own money into an application service > > > > provider who proposed to go IPv6-only in the near future. > > > > > > > >> It seems to me that requiring all services to > > > >> have IPv4 addresses is directly counter to the > > > >> general IETF theme of promoting IPv6 transition. > > > > > > > > I try to avoid the word "transition" and focus on co-existence. > > > > Also, the "universal deployment of IPv6" does not imply > > > > "deployment of IPv6-only services". So I'm not sure that this > > > > is a current goal for the IETF. It seems like something that > > > > lies quite some years in the future. > > > > > > Seems to me, then, we can comfortably postpone serious work on NAT[v4-- > > > >v6] until (and if) we find we really need it... > > > > Fully agree. +1 > > > > In last year, we had some mobile providers told us they might have IPv6-only mobile devices. But now, the situation has changed. We are told all major mobile OSes support or plan to support, in short time scale, dual stack; and at their experimental measurement, running dual stack is not tha= t computational consumption as they original thought. Without real traffic, keeping dual stack on is almost negligible. As long as there have no duplicated traffic for the same application, dual stack is not expensive than IPv4/Ipv6 single stack. So, the conclusion is even mobile devices woul= d be dual stack. There won't be IPv6-only devices for a long while. > > > > My understanding is different. > > In fact, I am a mobile operator that has beta ipv6-only capable devices that will be launched soon. > > Yes, we have mobile operator customers who are strategically choose IPv6-only network + Nat64. What I said above is the information I go= t from Handset devices perspective. > We have ipv6-only handsets that work well. There is no cost difference at the ue, but cost in the core network is the challenge for dual stack. Given that customers will not pay more for ipv6, the network cannot cost more to deliver the service over ipv6. > Furthermore, dual-stack in pre-release 9 networks is 2x the pdp , which generally translates to 2x the cost (lincenses, signalling, mobility events= , session setup, authetication...). > > These cost may not necessary for the handset devices depends on how mobile provider operates the network. These abovementioned operational cost can be handled by layer 2. Then, in layer 3, dual stack has almost the same cost with single IPv4/IPv6 stack. > Agreed, these are packet core cost. I am not sure what you mean about cost in layer 2, can you be more specific? All those cost I outlined are essentially layer 2 costs, those cost double in dual stack in current gsm and umts networks, and therefore dual stack is a bad business case in gsm and umts networks. > This case is different in LTE, but the LTE ramp rate is still very very small compared to gsm and umts.... > > and dual stack fundamentally does not solve private and public address exhaustion that most mobile providers are currently challenged with, since dual stack requires the ipv4 address that are ....exhausted.... so if ipv4 exhaustion is a tactical business problem, dual stack is not the answer... and yes, the devices are in the pipeline > > From last year, when we say dual stack, we do NOT mean IPv6 + public IPv4. It can be IPv6 + private IPv4, too. This may request more operational cost at network provider for CGN. But from handset perspective, they do not care IPv4 private or public address, unless there are considerable performance different. > Agreed, once again the core network is the costly part, not the ue. Regarding core network costs, the large mobile operators have exhausted bot= h public and private addresses, and now in some cases use bogon addresses. This address exhaustion in ipv4 is driving expensive architecture changes (paritioning multiple rfc1918 realms ...) that can only be relieved by stopping ipv4 growth.... which means growing in ipv6 only. My only point is that ipv6-only is real in mobile, expect to see it in the near term. I have been running it in beta for 18 months and we are going production real soon now. Cb > Sheng > > Cb > > > Sheng > > > > > - Ralph > > > > > > > > > > > Regards > > > > > > > > Brian > > > > > > > >> Perhaps instead you meant that there are not any > > > >> credible possibilities for NAT[v4-->v6]. I am > > > >> willing to agree that as far as I understand it > > > >> the alternatives (as of now) have problems of either > > > >> scalability or maybe vulnerability to DoS attacks. > > > >> I think these are problems that can be solved, > > > >> and they would be solved faster in a working group. > > > >> > > > >> Looked at another way, if [behave] shuts down > > > >> without working on NAT[v4-->v6], then it can be > > > >> seen as sending a strong message that the IETF > > > >> believes that all services and websites really need > > > >> to maintain IPv4 addressability ad infinitum > > > >> [or at least all commercially viable ones]. > > > >> > > > >> Regards, > > > >> Charlie P. > > > >> > > > >> _______________________________________________ > > > >> 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 > > > > > > _______________________________________________ > > > 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 > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > --000e0cd4841a2a390504a9f5c12a Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable


On Aug 7, 2011 7:09 PM, "Jiangsheng" <jiangsheng@huawei.com> wrote:
>
> Oops=85 The previous email was sent with any information by wrong butt= on.
>
> =A0
>
> From: behave-bounces@ietf.o= rg [mailto:behave-bounces@ie= tf.org] On Behalf Of Cameron Byrne
> Sent: Monday, August 08, 2011 9:54 AM
> To: Jiangsheng
> Cc: Charles E. Perkins; behave@ietf= .org; Andrew Sullivan; Ralph Droms
> Subject: Re: [BEHAVE] Closing the behave WG
>
> =A0
>
>
> On Aug 7, 2011 6:35 PM, "Jiangsheng" <jiangsheng@huawei.com> wrote:
> >
> > > Brian, et al.,
> > >
> > > On Aug 5, 2011, at 5:25 PM 8/5/11, Brian E Carpenter wrote:<= br> > > >
> > > > Charlie,
> > > >
> > > > On 2011-08-06 08:48, Charles E. Perkins wrote:
> > > >>
> > > >> Hello Andrew,
> > > >>
> > > >> On 8/5/2011 10:44 AM, Andrew Sullivan wrote:
> > > >>
> > > >>> On Thu, Aug 04, 2011 at 11:56:10AM -0700, Charl= es E. Perkins wrote:
> > > >>>
> > > >>>> I really think that NAT[v4-->v6] is impo= rtant as
> > > >>>> a perhaps crucial part of the transition st= ory.
> > > >>>
> > > >>> I would like to see the argument for this.
> > > >>
> > > >> If we don't have NAT[v4-->v6], then IPv6-onl= y
> > > >> services are not going to be available to most
> > > >> of the Internet for a really long time.
> > > >>
> > > >> Which, I reckon, means that all services are going<= br> > > > >> to be either IPv4-only or dual-stack for a really > > > >> long time.
> > > >
> > > > Correct. I've regarded that as a given for some yea= rs now.
> > > > I wouldn't put any of my own money into an applicat= ion service
> > > > provider who proposed to go IPv6-only in the near futur= e.
> > > >
> > > >> It seems to me that requiring all services to
> > > >> have IPv4 addresses is directly counter to the
> > > >> general IETF theme of promoting IPv6 transition. > > > >
> > > > I try to avoid the word "transition" and focu= s on co-existence.
> > > > Also, the "universal deployment of IPv6" does= not imply
> > > > "deployment of IPv6-only services". So I'= m not sure that this
> > > > is a current goal for the IETF. It seems like something= that
> > > > lies quite some years in the future.
> > >
> > > Seems to me, then, we can comfortably postpone serious work = on NAT[v4--
> > > >v6] until (and if) we find we really need it...
> >
> > Fully agree. +1
> >
> > In last year, we had some mobile providers told us they might hav= e IPv6-only mobile devices. But now, the situation has changed. We are told= all major mobile OSes support or plan to support, in short time scale, dua= l stack; and at their experimental measurement, running dual stack is not t= hat computational consumption as they original thought. Without real traffi= c, keeping dual stack on is almost negligible. As long as there have no dup= licated traffic for the same application, dual stack is not expensive than = IPv4/Ipv6 single stack. So, the conclusion is even mobile devices would be = dual stack. There won't be IPv6-only devices for a long while.
> >
>
> My understanding is different.
>
> In fact, I am a mobile operator that has beta ipv6-only capable device= s that will be launched soon.
>
> <Sheng> Yes, we have mobile operator customers who are strategic= ally choose IPv6-only network + Nat64. What I said above is the information= I got from Handset devices perspective.
>

We have ipv6-only handsets that work well. There is no cost difference a= t the ue, but cost in the core network is the challenge for dual stack. Giv= en that customers will not pay more for ipv6, the network cannot cost more = to deliver the service over ipv6.

> Furthermore, dual-stack in pre-release 9 networks is 2x the pdp , w= hich generally translates to 2x the cost (lincenses, signalling, mobility e= vents, session setup, authetication...).
>
> <Sheng> These cost may not necessary for the handset devices dep= ends on how mobile provider operates the network. These abovementioned oper= ational cost can be handled by layer 2. Then, in layer 3, dual stack has al= most the same cost with single IPv4/IPv6 stack.
>

Agreed, these are packet core cost.

I am not sure what you mean about cost in layer 2, can you be more speci= fic?=A0 All those cost I outlined are essentially layer 2 costs, those cost= double in dual stack in current gsm and umts networks, and therefore dual = stack is a bad business case in gsm and umts networks.

> This case is different in LTE, but the LTE ramp rate is still very = very small compared to gsm and umts....
>
> and dual stack fundamentally does not solve private and public address= exhaustion that most mobile providers are currently challenged with, since= dual stack requires the ipv4 address that are ....exhausted.... so if ipv4= exhaustion is a tactical business problem, dual stack is not the answer...= and yes, the devices are in the pipeline
>
> <Sheng> From last year, when we say dual stack, we do NOT mean I= Pv6 + public IPv4. It can be IPv6 + private IPv4, too. This may request mor= e operational cost at network provider for CGN. But from handset perspectiv= e, they do not care IPv4 private or public address, unless there are consid= erable performance different.
>

Agreed, once again the core network is the costly part, not the ue. Rega= rding core network costs, the large mobile operators have exhausted both pu= blic and private addresses, and now in some cases use bogon addresses.=A0 T= his address exhaustion in ipv4 is driving expensive architecture changes (p= aritioning multiple rfc1918 realms ...) that can only be relieved by stoppi= ng ipv4 growth.... which means growing in ipv6 only.

My only point is that ipv6-only is real in mobile, expect to see it in t= he near term. I have been running it in beta for 18 months and we are going= production real soon now.

Cb
> Sheng
>
> Cb
>
> > Sheng
> >
> > > - Ralph
> > >
> > > >
> > > > Regards
> > > >
> > > > =A0 Brian
> > > >
> > > >> Perhaps instead you meant that there are not any > > > >> credible possibilities for NAT[v4-->v6]. =A0I am=
> > > >> willing to agree that as far as I understand it
> > > >> the alternatives (as of now) have problems of eithe= r
> > > >> scalability or maybe vulnerability to DoS attacks.<= br> > > > >> I think these are problems that can be solved,
> > > >> and they would be solved faster in a working group.=
> > > >>
> > > >> Looked at another way, if [behave] shuts down
> > > >> without working on NAT[v4-->v6], then it can be<= br> > > > >> seen as sending a strong message that the IETF
> > > >> believes that all services and websites really need=
> > > >> to maintain IPv4 addressability ad infinitum
> > > >> [or at least all commercially viable ones].
> > > >>
> > > >> Regards,
> > > >> Charlie P.
> > > >>
> > > >> _______________________________________________
> > > >> Behave mailing list
> > > >> Behave@ietf.org<= /a>
> > > >> https://www.ietf.org/mailman/listinfo/behave
> > > >>
> > > > _______________________________________________
> > > > Behave mailing list
> > > > Behave@ietf.org<= br> > > > > https://www.ietf.org/mailman/listinfo/behave
> > >
> > > _______________________________________________
> > > Behave mailing list
> > > Behave@ietf.org
> > > htt= ps://www.ietf.org/mailman/listinfo/behave
> > _______________________________________________
> > Behave mailing list
> > Behave@ietf.org
> > https://= www.ietf.org/mailman/listinfo/behave
>
>
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.i= etf.org/mailman/listinfo/behave
>

--000e0cd4841a2a390504a9f5c12a-- From jiangsheng@huawei.com Mon Aug 8 03:06: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 9865921F8AAC for ; Mon, 8 Aug 2011 03:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.104 X-Spam-Level: X-Spam-Status: No, score=-6.104 tagged_above=-999 required=5 tests=[AWL=0.494, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 rBZ8f-Icz7yT for ; Mon, 8 Aug 2011 03:06:44 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 2BBBC21F8AA9 for ; Mon, 8 Aug 2011 03:06:44 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPL000JFTFVJT@szxga03-in.huawei.com> for behave@ietf.org; Mon, 08 Aug 2011 18:07:07 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPL0094ETFTYO@szxga03-in.huawei.com> for behave@ietf.org; Mon, 08 Aug 2011 18:07:07 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml203-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACZ78668; Mon, 08 Aug 2011 18:07:05 +0800 (CST) Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 08 Aug 2011 18:07:04 +0800 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.17]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0270.001; Mon, 08 Aug 2011 18:07:06 +0800 Date: Mon, 08 Aug 2011 10:07:04 +0000 From: Jiangsheng In-reply-to: X-Originating-IP: [10.110.98.152] To: Cameron Byrne Message-id: <5D36713D8A4E7348A7E10DF7437A4B9201228640@SZXEML506-MBS.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_+BiTvNCXnbGfkt/HAKHwng)" Content-language: zh-CN Accept-Language: en-GB, zh-CN, en-US Thread-topic: [BEHAVE] Closing the behave WG Thread-index: AcxSOz1+np/vF0xnTkWaM1paeuvypwAOpfOAAAfSRQAAL8ukAAAGbpQAAAFFvQAAACj7gAB9ph0w//+BU4D//3iRwIAAnAuA//8Hz/A= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <285AA91F41624C6B963A45FECC73F56E@davidPC> <4E3AEB4A.8080202@wichorus.com> <20110805174442.GR49271@shinkuro.com> <4E3C5734.6000009@wichorus.com> <4E3C5FBE.4090904@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B92012282A2@SZXEML506-MBS.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B9201228345@SZXEML506-MBS.china.huawei.com> Cc: "Charles E. Perkins" , "behave@ietf.org" , Ralph Droms , Andrew Sullivan Subject: Re: [BEHAVE] Closing the behave WG 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, 08 Aug 2011 10:06:45 -0000 --Boundary_(ID_+BiTvNCXnbGfkt/HAKHwng) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT I am not sure what you mean about cost in layer 2, can you be more specific? All those cost I outlined are essentially layer 2 costs, those cost double in dual stack in current gsm and umts networks, and therefore dual stack is a bad business case in gsm and umts networks. We share the same understanding of layer 2 cost. What I meant was "lincenses, signalling, mobility events, session setup, authentication" can be handled by layer 2. Then IPv6/IPv4 authentication/lincenses may not be needed. Mobility events is layer 2 events, should not increase the cost whether it is dual-stack or single. Session setup/signalling are application-initiated. As long as no duplication, session setup/signalling would actually though single stack even on dual stack platform. Overall, my point is dual-stack does not bring too much extra cost from handset perspective. So, single-stack handset would not be one of the critic reasons any more. (Of course, provider cost would increase. Providers may choose IPv6-only network for many reasons, including cost. But it should another discuss topic, I guess.) Sheng --Boundary_(ID_+BiTvNCXnbGfkt/HAKHwng) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

I am not sure what you mean about cost in layer 2, can you be more specific?  All those cost I outlined are essentially layer 2 costs, those cost double in dual stack in current gsm and umts networks, and therefore dual stack is a bad business case in gsm and umts networks.

<Sheng> We share the same understanding of layer 2 cost. What I meant was “lincenses, signalling, mobility events, session setup, authentication” can be handled by layer 2. Then IPv6/IPv4 authentication/lincenses may not be needed. Mobility events is layer 2 events, should not increase the cost whether it is dual-stack or single. Session setup/signalling are application-initiated. As long as no duplication, session setup/signalling would actually though single stack even on dual stack platform.

Overall, my point is dual-stack does not bring too much extra cost from handset perspective. So, single-stack handset would not be one of the critic reasons any more. (Of course, provider cost would increase. Providers may choose IPv6-only network for many reasons, including cost. But it should another discuss topic, I guess.)

Sheng

--Boundary_(ID_+BiTvNCXnbGfkt/HAKHwng)-- From charliep@wichorus.com Mon Aug 8 09:37:11 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBA2921F86D7 for ; Mon, 8 Aug 2011 09:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECOzFhYqs+x0 for ; Mon, 8 Aug 2011 09:37:11 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id E9B1221F8801 for ; Mon, 8 Aug 2011 09:37:10 -0700 (PDT) Received: from [138.111.58.2] (helo=[172.17.96.56]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1QqSpa-0001je-NL for behave@ietf.org; Mon, 08 Aug 2011 12:37:35 -0400 Message-ID: <4E4010CA.8030506@wichorus.com> Date: Mon, 08 Aug 2011 09:37:30 -0700 From: "Charles E. Perkins" Organization: WiChorus Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "behave@ietf.org" References: <285AA91F41624C6B963A45FECC73F56E@davidPC><4E3AEB4A.8080202@wichorus.com> <20110805174442.GR49271@shinkuro.com><4E3C5734.6000009@wichorus.com> <20110805212447.GF51956@shinkuro.com><4E3C7C85.8060602@wichorus.com>, <20110806015059.GB53096@shinkuro.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86d92e03b36faafb23b8bc1083798f232a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 138.111.58.2 Subject: Re: [BEHAVE] Closing the behave WG 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, 08 Aug 2011 16:37:11 -0000 Hello folks, On 8/5/2011 2:24 PM, Andrew Sullivan wrote: > On Fri, Aug 05, 2011 at 04:28:05PM -0700, Charles E. Perkins wrote: > >> Then we end up where it's no longer so democratic to offer >> a website, because the hosting site has to have a v4 address. > > This seems to be conflating "someone still has to connect via IPv4" > with "most people have to connect via IPv4". Put simply, if someone has a website or service, and they want it to be available to the Internet, it _HAS_ to be addressable by IPv4 right now. And this situation will persist until either: - NATv4v6 exists, or - the Internet is predominantly IPv6 No choice, resulting from IETF decisions. Did IETF mandate the result, or just cause it? >> it takes for IPv4 traffic to disappear. I am much >> more concerned about how long the IETF will practically >> mandate IPv4 addressability for all new websites (and > > I just don't get how the IETF is mandating anything (never mind how > seriouslt the IETF's mandates are taken. See above. >>> But so far, nobody has actually proposed anything that would solve >>> them. >> >> Ouch. > > Perhaps I'm missing some draft, then. Hit me with the clue-stick, > please. I'm almost always wrong about everything, so I'm prepared to > be wrong here too. I was thinking of several drafts including IVI, DIVI, SIPNAT, and another draft from Dan Wing. >>> Instead, what we're getting is yet more spackle on top of >>> patches like NAT64/DNS64. >> >> >> Perhaps I am missing the point, but if an IPv4 host >> wants to resolve the name of an IPv6-only host, isn't >> DNS tautologically required to help out with that? > > Yes. And my claim is that this is a problem that absolutely nobody > actually has, nor will have for some time to come. I would be > astonished to learn otherwise. Of course they aren't asking for it now. There's practically no IPv6 Internet (percentage-wise). And, to the point, I claim that the action of neglecting NATv4v6 will lengthen the time until IPv6 Internet dominates. > ........... As soon as we get to the point where > there is serious IPv6-only traffic, all the IPv4-only people will (1) > get a real clue and go dual stack or (2) do (1) only with more > invasive technology. Well, we're looking at under 0.2%, and it's been over 10 years. > If you're telling me that (2) can be done cleanly and in a > well-standardized way, then please point me to the draft that doesn't > include things like, "Except Skype is broken." The above drafts all have substantial problems. These problems would likely be fixed by working group actions. There is not yet a clean solution, but I think the above- mentioned solutions can have their sins washed away. >> Hmmm... Just this morning, someone quoted Mark Townsley as >> saying: >> >> "If you have something that solves 90% of a problem for 90% >> of the population, you have a product to ship" > > Right. That's not the same as, "If you have something that solves 50% > of a problem for 50% of the population, except that it breaks other > things all over the network." Well, I am not promising anyone a rose garden. Look at it this way. We can enable some support for IPv6-only services. IPv4 addressability will become more expensive. IPv6 addressability will become cheaper (much cheaper). If we can arrange it so that IPv4 access to IPv6-only services is only slightly degraded, then we could significantly speed up the adoption of IPv6 for websites, services, peer-to-peer, etc. The percentage degradation will affect the speed of adoption for IPv6 services. With zero degradation, everyone would move to IPv6 that much faster. With large degradation, NATv4->v6 just would not help very much. With nonzero but small degradation, IPv4 access will be seen as feasible but inferior to IPv6 access --> incentive for the Internet to move to IPv6 to get better access to the growing population of IPv6-only websites. Right now the achievable percentage degradation is simply not known. But we know that the current percentage degradation is 100%. Regards, Charlie P. PS to Andrew: This is the same as what I sent you earlier, with minor revisions, when I did not have access to this account. From internet-drafts@ietf.org Tue Aug 9 06:37: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 5DD2021F8BF3; Tue, 9 Aug 2011 06:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 QCsFNhfwUwSC; Tue, 9 Aug 2011 06:37:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D820221F8B85; Tue, 9 Aug 2011 06:37:25 -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.57 Message-ID: <20110809133725.20875.30137.idtracker@ietfa.amsl.com> Date: Tue, 09 Aug 2011 06:37:25 -0700 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action: draft-ietf-behave-64-analysis-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: Tue, 09 Aug 2011 13:37:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Behavior Engineering for Hindrance Av= oidance Working Group of the IETF. Title : Analysis of Stateful 64 Translation Author(s) : Reinaldo Penno Tarun Saxena Mohamed Boucadair Senthil Sivakumar Filename : draft-ietf-behave-64-analysis-04.txt Pages : 15 Date : 2011-08-09 Due to specific problems, NAT-PT was deprecated by the IETF as a mechanism to perform IPv6-IPv4 translation. Since then, new efforts have been undertaken within IETF to standardize alternative mechanisms to perform IPv6-IPv4 translation. This document evaluates how the new stateful translation mechanisms avoid the problems that caused the IETF to deprecate NAT-PT. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-64-analysis-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-64-analysis-04.txt From internet-drafts@ietf.org Wed Aug 10 00:36: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 4D2B121F85E3; Wed, 10 Aug 2011 00:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 Kqeu0JZ0Agpd; Wed, 10 Aug 2011 00:36:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCB1221F8571; Wed, 10 Aug 2011 00:36:32 -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.57 Message-ID: <20110810073632.22044.16460.idtracker@ietfa.amsl.com> Date: Wed, 10 Aug 2011 00:36:32 -0700 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action: draft-ietf-behave-v4v6-bih-06.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 07:36:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Behavior Engineering for Hindrance Av= oidance Working Group of the IETF. Title : Dual Stack Hosts Using "Bump-in-the-Host" (BIH) Author(s) : Bill Huang Hui Deng Teemu Savolainen Filename : draft-ietf-behave-v4v6-bih-06.txt Pages : 29 Date : 2011-08-10 Bump-In-the-Host (BIH) is a host-based IPv4 to IPv6 protocol translation mechanism that allows a class of IPv4-only applications that work through NATs to communicate with IPv6-only peers. The host on which applications are running may be connected to IPv6-only or dual-stack access networks. BIH hides IPv6 and makes the IPv4-only applications think they are talking with IPv4 peers by local synthesis of IPv4 addresses. This draft obsoletes RFC 2767 and RFC 3338. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-v4v6-bih-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-v4v6-bih-06.txt From teemu.savolainen@nokia.com Wed Aug 10 00:40: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 1913B21F85B2 for ; Wed, 10 Aug 2011 00:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 Ih+l-tNfo50E for ; Wed, 10 Aug 2011 00:40:25 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 0379721F85B8 for ; Wed, 10 Aug 2011 00:40:24 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p7A7epNj019522; Wed, 10 Aug 2011 10:40:52 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 10 Aug 2011 10:40:46 +0300 Received: from 008-AM1MMR1-005.mgdnok.nokia.com (65.54.30.60) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 10 Aug 2011 09:40:37 +0200 Received: from 008-AM1MPN1-031.mgdnok.nokia.com ([169.254.1.23]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.01.0323.002; Wed, 10 Aug 2011 09:40:37 +0200 From: To: , Thread-Topic: [BEHAVE] AD review of draft-ietf-behave-v4v6-bih-05 Thread-Index: AcxSL86/Ib1EjQ75T7STyzdBpariUwC0VoNw Date: Wed, 10 Aug 2011 07:40:37 +0000 Message-ID: <916CE6CF87173740BC8A2CE44309696201423C00@008-AM1MPN1-031.mgdnok.nokia.com> References: <7AA26F5380BF4CFCBAAA20D91C13FD65@davidPC> In-Reply-To: <7AA26F5380BF4CFCBAAA20D91C13FD65@davidPC> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Company Confidential;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IkYE9kFbll23ieqQmAZnFdxANm01tNy+DNF2XWeZCd9Kj6DesAjI++uUK6GLfn9PVtxFDSE65IECHf2yHFEg7bAMVcORqQvqssmnjKeOk5GPh9CINhOQ2Wh+TSurhE6+/4PcmkWmDVRqpcwVSmiFZRc89I6SogkTA5mZfHGGU5Z67iYkPnGeCbkTTSbv+bwJLJd4hJCrG1MhLw7QNNINDqrg4r5/5W2T1OGzcWo6crrRESECZl2+PsLtaR+oQMZ/UA== x-originating-ip: [10.162.78.119] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 10 Aug 2011 07:40:46.0306 (UTC) FILETIME=[D0FB0420:01CC5730] X-Nokia-AV: Clean Subject: Re: [BEHAVE] AD review of draft-ietf-behave-v4v6-bih-05 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, 10 Aug 2011 07:40:26 -0000 Hi David, Thank you very much for your review. The draft-ietf-behave-v4v6-bih-06 atte= mpts to answer all the issues you raised. Below inline are few additional c= omments. The diff to -05 is available here: http://tools.ietf.org/rfcdiff?url2=3Ddra= ft-ietf-behave-v4v6-bih-06 Thank you, Teemu > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf > Of ext David Harrington > Sent: 04. elokuuta 2011 01:51 > To: draft-ietf-behave-v4v6-bih@tools.ietf.org; behave@ietf.org; behave- > chairs@tools.ietf.org > Subject: [BEHAVE] AD review of draft-ietf-behave-v4v6-bih-05 =20 > 2.3 RECOMMENDS the socket API layer option. When is it appropriate to use > the other option? When software implementing API layer cannot be changed, for example, when i= t is only possibly to add virtual interface drivers (of sorts) and not to t= ouch API implementation. For example, an operating system might be complete= ly closed source providing only possibilities to create plug-ins at network= layer, hence making it possible to only have the network layer implementat= ion. > in 2.3.2, I don't like the wording in "In order to properly support DNSSE= C, the > ENR SHOULD be implemented at the socket API level. If the socket API leve= l > implementation is not possible, DNSSEC support SHOULD be provided by othe= r > means." Properly support is not a technical phrase; do you mean to be > compliant to dnssec? Do you mean to secure the DNS environment? > If the socket API is not implemented, why isn't DNSSEC support MUST be > provided by other means? If an implementation does not provide dnssec > support by other means, then what happens to the security properties of t= he > trusted environment? would not doing this create a vulnerability? The -06 now recommends API implementation option as with that DNSSEC suppor= t comes naturally. If ENR is implemented at the network layer, well it may = support DNSSEC, but I hesitate to use MUST when it comes to DNSSEC support = on hosts (I still don't recall IETF document that would set DNSSEC as MUST = for host). > in 7, "The security considerations of BIH mostly relies on that of [RFC61= 46]." Do > you mean "The security considerations found in RFC6146 apply, with the > following additional considerations specific to BIH"? > in 7, it says "the differences are due to ..." - the differences between = what and > what? Do you mean between 6146 and this document? If so, simply discuss t= he > considerations for this document. Doing this as a comparison to the other > document is a bit confusing, and would really require the reader to have = both > documents open and to do a diff to understand your text. The section 7 security considerations is now fully rewritten by fetching qu= ite some content from RFC6146 and RFC6147 security considerations and modif= ying those to suit BIH. From pacosaddress@googlemail.com Wed Aug 10 03:49:59 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D74F21F86A9 for ; Wed, 10 Aug 2011 03:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.692 X-Spam-Level: X-Spam-Status: No, score=-2.692 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 lC5GkmO+4xUO for ; Wed, 10 Aug 2011 03:49:58 -0700 (PDT) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by ietfa.amsl.com (Postfix) with ESMTP id C744C21F8698 for ; Wed, 10 Aug 2011 03:49:58 -0700 (PDT) Received: by iye1 with SMTP id 1so939385iye.27 for ; Wed, 10 Aug 2011 03:50:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Jyo0S1kp7gOZc8eOHatGahc25PdCX9GVKQEhIOjkQgE=; b=iW+qcmSELcfx8NNqePa9z8T0REbSKHZGXmZbSubRK3i2Mt5b2VuFcscZZ9QCH9/sza KtYWLthQIatWb5g6ph8CjBpM30Lr1Bd3GdzGBSxf10qrB9eJ3tfeE2S8jc7Q73Agfi9o oR78s4GhucRuNw0qEkHqDS9T2VrJfJp/hNfiA= MIME-Version: 1.0 Received: by 10.231.119.161 with SMTP id z33mr10085198ibq.91.1312973427458; Wed, 10 Aug 2011 03:50:27 -0700 (PDT) Received: by 10.231.146.199 with HTTP; Wed, 10 Aug 2011 03:50:27 -0700 (PDT) In-Reply-To: <20110809133725.20875.30137.idtracker@ietfa.amsl.com> References: <20110809133725.20875.30137.idtracker@ietfa.amsl.com> Date: Wed, 10 Aug 2011 12:50:27 +0200 Message-ID: From: Paco Cortes To: rpenno@juniper.net, tasaxena@cisco.com, mohamed.boucadair@orange-ftgroup.com, ssenthil@cisco.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: behave@ietf.org Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-64-analysis-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: Wed, 10 Aug 2011 10:49:59 -0000 Hi, In Table 1, the "proxy correspondent node for MIPv6" issue should be classified as NOT NAT-PT specific, shouldn't it? Is it a typo that you wrote "yes" in the corresponding cell, or is there a dependency that I am missing? +---------------+----------+---------+----------+---------+---------+ | Proxy | Yes | Yes | No | No | No | | correspondent | | | | | | | node for | | | | | | | MIPv6 | | | | | | +---------------+----------+---------+----------+---------+---------+ br, Paco 2011/8/9 : > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. This draft is a work item of the Behavior Engineering for Hindrance = Avoidance Working Group of the IETF. > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Analysis of Stateful 64 Transl= ation > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Reinaldo Penno > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Tarun Saxena > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Mohamed Boucadair > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Senthil Sivakumar > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-behave-64-analysis-04= .txt > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 15 > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-08-09 > > =A0 Due to specific problems, NAT-PT was deprecated by the IETF as a > =A0 mechanism to perform IPv6-IPv4 translation. =A0Since then, new effort= s > =A0 have been undertaken within IETF to standardize alternative > =A0 mechanisms to perform IPv6-IPv4 translation. =A0This document evaluat= es > =A0 how the new stateful translation mechanisms avoid the problems that > =A0 caused the IETF to deprecate NAT-PT. > > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-behave-64-analysis-04.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-64-analysis-04.txt > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From nejc@skoberne.net Wed Aug 10 07:36: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 1CB3321F8AAC for ; Wed, 10 Aug 2011 07:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 ChGiG29EDvXS for ; Wed, 10 Aug 2011 07:36:45 -0700 (PDT) Received: from mail.tnode.com (common.tnode.com [91.185.203.243]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD3021F8A66 for ; Wed, 10 Aug 2011 07:36:44 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.tnode.com (Postfix) with ESMTP id 80CCA22780FF for ; Wed, 10 Aug 2011 16:37:14 +0200 (CEST) Received: from mail.tnode.com ([127.0.0.1]) by localhost (mail.tnode.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ePw1prsK+aRF for ; Wed, 10 Aug 2011 16:37:12 +0200 (CEST) Received: from [158.125.103.63] (co-staff-103-063.lut.ac.uk [158.125.103.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejc@skoberne.net) by mail.tnode.com (Postfix) with ESMTPSA id E4B5222780FE for ; Wed, 10 Aug 2011 16:37:11 +0200 (CEST) Message-ID: <4E429796.5000200@skoberne.net> Date: Wed, 10 Aug 2011 15:37:10 +0100 From: =?windows-1252?Q?Nejc_=8Akoberne?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: behave@ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: [BEHAVE] Comments on draft-ietf-behave-lsn-requirements-02 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 14:36:46 -0000 Dear all, I have a few comments on draft-ietf-behave-lsn-requirements-02. You say in section »4. Logging«: In order to be able to do this, the CGN would need to log the following information for each mapping created: o internal source address [(or tunnel end point identifier)] o internal source port o external source address o external source port o destination address (but see below) o destination port (but see below) o timestamp I wonder why do I need to log the »internal source port« in order to achieve legal traceability? If we look at different CGN schemes: 1. NAT444: here we need only IPv6 internal source address in order to uniquely identify the customer 2. DS-Lite: here we need only IPv6 tunnel end point of the customer's CPE in order to uniquely identify the customer 3. NAT64: here we need only IPv6 source address in order to uniquely identify the customer Do you agree? If we wanted to uniquely identify _the machine_ in the customer's network, _then_ we could also log »internal source port«, but we would probably have to on logging on the CPE as well, which I don't think is feasible nor desirable. Also, I extended the first bullet point since it is not necessarily the actual source address you need to log in order to identify the customer, but can be a tunnel end point as well (DS-Lite). Do you agree? Thanks, Nejc From ietfdbh@comcast.net Wed Aug 10 07:51: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 C97AE21F8AA8 for ; Wed, 10 Aug 2011 07:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wedYJvOPChkn for ; Wed, 10 Aug 2011 07:51:07 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by ietfa.amsl.com (Postfix) with ESMTP id 1E98921F85AC for ; Wed, 10 Aug 2011 07:51:06 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta01.westchester.pa.mail.comcast.net with comcast id Jeq61h00D0bG4ec51erfqp; Wed, 10 Aug 2011 14:51:39 +0000 Received: from davidPC ([67.189.235.106]) by omta03.westchester.pa.mail.comcast.net with comcast id Jerd1h00E2JQnJT3Perepn; Wed, 10 Aug 2011 14:51:39 +0000 From: "David Harrington" To: , References: <7AA26F5380BF4CFCBAAA20D91C13FD65@davidPC> <916CE6CF87173740BC8A2CE44309696201423C00@008-AM1MPN1-031.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE44309696201423C00@008-AM1MPN1-031.mgdnok.nokia.com> Date: Wed, 10 Aug 2011 10:51:25 -0400 Message-ID: <03D03CFF17E541F2A435C9D59451C0F7@davidPC> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.17609 thread-index: AcxSL86/Ib1EjQ75T7STyzdBpariUwC0VoNwAJUD/FA= Cc: 'Dave Thaler' , 'Dan Wing' Subject: Re: [BEHAVE] AD review of draft-ietf-behave-v4v6-bih-05 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, 10 Aug 2011 14:51:07 -0000 Hi, comments inline. > > 2.3 RECOMMENDS the socket API layer option. When is it > appropriate to use > > the other option? > > When software implementing API layer cannot be changed, for > example, when it is only possibly to add virtual interface > drivers (of sorts) and not to touch API implementation. For > example, an operating system might be completely closed > source providing only possibilities to create plug-ins at > network layer, hence making it possible to only have the > network layer implementation. You missed the point. You need to discuss IN THE DOCUMENT when it is acceptable to not follow the recommendation. > > > in 2.3.2, I don't like the wording in "In order to properly > support DNSSEC, the > > ENR SHOULD be implemented at the socket API level. If the > socket API level > > implementation is not possible, DNSSEC support SHOULD be > provided by other > > means." Properly support is not a technical phrase; do you > mean to be > > compliant to dnssec? Do you mean to secure the DNS environment? > > If the socket API is not implemented, why isn't DNSSEC > support MUST be > > provided by other means? If an implementation does not > provide dnssec > > support by other means, then what happens to the security > properties of the > > trusted environment? would not doing this create a vulnerability? > > The -06 now recommends API implementation option as with that > DNSSEC support comes naturally. If ENR is implemented at the > network layer, well it may support DNSSEC, but I hesitate to > use MUST when it comes to DNSSEC support on hosts (I still > don't recall IETF document that would set DNSSEC as MUST for host). see below > > > in 7, "The security considerations of BIH mostly relies on > that of [RFC6146]." Do > > you mean "The security considerations found in RFC6146 > apply, with the > > following additional considerations specific to BIH"? > > in 7, it says "the differences are due to ..." - the > differences between what and > > what? Do you mean between 6146 and this document? If so, > simply discuss the > > considerations for this document. Doing this as a > comparison to the other > > document is a bit confusing, and would really require the > reader to have both > > documents open and to do a diff to understand your text. > > The section 7 security considerations is now fully rewritten > by fetching quite some content from RFC6146 and RFC6147 > security considerations and modifying those to suit BIH. > > FYI. I think the changes include a lot of changes to normative text. Therefore the draft probably requires WG review. I am working with Dan and Dave, who should handle that process. David Harrington Director, IETF Transport Area ietfdbh@comcast.net (preferred for ietf) dbharrington@huaweisymantec.com +1 603 828 1401 (cell) From xing@cernet.edu.cn Thu Aug 11 01:49: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 3922021F86C2 for ; Thu, 11 Aug 2011 01:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.752 X-Spam-Level: X-Spam-Status: No, score=-99.752 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, 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 5ZQmER4Cu8HE for ; Thu, 11 Aug 2011 01:49:35 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with SMTP id AF9AC21F86C0 for ; Thu, 11 Aug 2011 01:49:34 -0700 (PDT) Received: from [127.0.0.1]([119.39.249.33]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm04e43d566; Thu, 11 Aug 2011 16:50:05 +0800 Message-ID: <4E4397B3.30301@cernet.edu.cn> Date: Thu, 11 Aug 2011 16:49:55 +0800 From: Xing Li User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; zh-CN; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: David Harrington References: <285AA91F41624C6B963A45FECC73F56E@davidPC> In-Reply-To: <285AA91F41624C6B963A45FECC73F56E@davidPC> Content-Type: multipart/alternative; boundary="------------040405060407050107090409" X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: cIpx0r0B Cc: behave@ietf.org Subject: Re: [BEHAVE] Closing the behave WG 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, 11 Aug 2011 08:49:37 -0000 This is a multi-part message in MIME format. --------------040405060407050107090409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit ? 2011/8/4 8:12, David Harrington ??: > Hi, > > As Responsible Area Director, I have received a request from the > behave WG chairs to consider closing the behave working group, rather > than rechartering to do additional work. I also vote for recharting. I was in the mic and said: "Since the IPv4 address pool is empty and the coexistence of IPv4 and IPv6 will not be ended in a short time, we need additional translation solutions; no matter it is NAT44 or NAT46". I think Behave is a suitable place to continue the general translation work, we have experts and energy. Besides, there are remaining works in the current charter, but no milestones (e.g. multicast). There are remaining issues mentioned in the Behave-WG RFCs (e.g. address extension and MIBs). I think we should at least have a complete set of documents. Regards, xing > The chairs and the IESG agree that closing the WG after completing the > current milestones would be a good thing, to signal that the chartered > behave work items supporting transition to IPv6 have been completed. > > During ietf81, the chairs discussed with the working group the > possible closing of the working group. Additional work, such as those > drafts identified in the chairs' slides, can be proposed for > completion in existing working groups (or in new working groups). None > of this would be automatic; the proponents would need to convince an > existing WG to adopt their draft, or would need to convince the IESG a > new working group is justified using the normal methods for requesting > a new working group. The behave chairs have agreed to serve as > technical advisors to working groups that take on such work, if > needed. > > In my opinion, the sense of the room was to support this closure. > > As Responsible area director, I plan to make a decision on WG closure > in the next few weeks, and would like to give the WG mailing list > members a chance to provide feedback on this proposed closure. Please > send substantive comments to the > behave@ietf.org mailing list by 2011-08-15, with the above Subject > line. > > David Harrington > Director, IETF Transport Area > ietfdbh@comcast.net (preferred for ietf) > dbharrington@huaweisymantec.com > +1 603 828 1401 (cell) > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > --------------040405060407050107090409 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 于 2011/8/4 8:12, David Harrington 写道: 
Hi,

As Responsible Area Director, I have received a request from the
behave WG chairs to consider closing the behave working group, rather
than rechartering to do additional work.

I also vote for recharting. I was in the mic and said: "Since the IPv4 address pool is empty and the coexistence of IPv4 and IPv6 will not be ended in a short time, we need additional translation solutions; no matter it is NAT44 or NAT46". I think Behave is a suitable place to continue the general translation work, we have experts and energy.

Besides, there are remaining works in the current charter, but no milestones (e.g. multicast). There are remaining issues mentioned in the Behave-WG RFCs (e.g. address extension and MIBs). I think we should at least have a complete set of documents.

Regards,

xing





The chairs and the IESG agree that closing the WG after completing the
current milestones would be a good thing, to signal that the chartered
behave work items supporting transition to IPv6 have been completed.

During ietf81, the chairs discussed with the working group the
possible closing of the working group. Additional work, such as those
drafts identified in the chairs' slides, can be proposed for
completion in existing working groups (or in new working groups). None
of this would be automatic; the proponents would need to convince an
existing WG to adopt their draft, or would need to convince the IESG a
new working group is justified using the normal methods for requesting
a new working group. The behave chairs have agreed to serve as
technical advisors to working groups that take on such work, if
needed. 

In my opinion, the sense of the room was to support this closure. 

As Responsible area director, I plan to make a decision on WG closure
in the next few weeks, and would like to give the WG mailing list
members a chance to provide feedback on this proposed closure. Please
send substantive comments to the
behave@ietf.org mailing list by 2011-08-15, with the above Subject
line.

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

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

--------------040405060407050107090409-- From xing@cernet.edu.cn Thu Aug 11 01:50:12 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D132421F8B0D for ; Thu, 11 Aug 2011 01:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.558 X-Spam-Level: X-Spam-Status: No, score=-98.558 tagged_above=-999 required=5 tests=[AWL=-1.069, BAYES_40=-0.185, 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 E-s72ThgvMwp for ; Thu, 11 Aug 2011 01:50:12 -0700 (PDT) Received: from cernet.edu.cn (cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with SMTP id CF83621F86D0 for ; Thu, 11 Aug 2011 01:50:11 -0700 (PDT) Received: from [127.0.0.1]([119.39.249.33]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm104e43d58e; Thu, 11 Aug 2011 16:50:44 +0800 Message-ID: <4E4397DE.1060801@cernet.edu.cn> Date: Thu, 11 Aug 2011 16:50:38 +0800 From: Xing Li User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; zh-CN; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "Charles E. Perkins" References: <285AA91F41624C6B963A45FECC73F56E@davidPC><4E3AEB4A.8080202@wichorus.com> <20110805174442.GR49271@shinkuro.com><4E3C5734.6000009@wichorus.com> <20110805212447.GF51956@shinkuro.com><4E3C7C85.8060602@wichorus.com>, <20110806015059.GB53096@shinkuro.com> <4E4010CA.8030506@wichorus.com> In-Reply-To: <4E4010CA.8030506@wichorus.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: cN2y0r0B Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Closing the behave WG 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, 11 Aug 2011 08:50:12 -0000 于 2011/8/9 0:37, Charles E. Perkins 写é“: > > Hello folks, > > On 8/5/2011 2:24 PM, Andrew Sullivan wrote: > >> On Fri, Aug 05, 2011 at 04:28:05PM -0700, Charles E. Perkins wrote: >> >>> Then we end up where it's no longer so democratic to offer >>> a website, because the hosting site has to have a v4 address. >> >> This seems to be conflating "someone still has to connect via IPv4" >> with "most people have to connect via IPv4". > > Put simply, if someone has a website or service, and they want > it to be available to the Internet, it _HAS_ to be addressable > by IPv4 right now. And this situation will persist until either: > - NATv4v6 exists, or > - the Internet is predominantly IPv6 > > No choice, resulting from IETF decisions. Did IETF mandate the > result, or just cause it? > Yes, this is the situation some ICPs are facing now. xing From xing@cernet.edu.cn Thu Aug 11 01:51: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 8EAA021F8B21 for ; Thu, 11 Aug 2011 01:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.683 X-Spam-Level: X-Spam-Status: No, score=-99.683 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, 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 00Zc9s510ONp for ; Thu, 11 Aug 2011 01:51:35 -0700 (PDT) Received: from cernet.edu.cn (cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with SMTP id 1A43021F86C7 for ; Thu, 11 Aug 2011 01:51:34 -0700 (PDT) Received: from [127.0.0.1]([119.39.249.33]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm04e43d59b; Thu, 11 Aug 2011 16:50:57 +0800 Message-ID: <4E4397EB.6030805@cernet.edu.cn> Date: Thu, 11 Aug 2011 16:50:51 +0800 From: Xing Li User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; zh-CN; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Cameron Byrne References: <285AA91F41624C6B963A45FECC73F56E@davidPC> <4E3AEB4A.8080202@wichorus.com> <20110805174442.GR49271@shinkuro.com> <4E3C5734.6000009@wichorus.com> <4E3C5FBE.4090904@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B92012282A2@SZXEML506-MBS.china.huawei.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030208040509060004020608" X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: cOfy0r0B Cc: "Charles E. Perkins" , "behave@ietf.org" , Ralph Droms , Andrew Sullivan , Jiangsheng Subject: Re: [BEHAVE] Closing the behave WG 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, 11 Aug 2011 08:51:37 -0000 This is a multi-part message in MIME format. --------------030208040509060004020608 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit ? 2011/8/8 9:54, Cameron Byrne ??: > > > On Aug 7, 2011 6:35 PM, "Jiangsheng" > wrote: > > > > > Brian, et al., > > > > > > On Aug 5, 2011, at 5:25 PM 8/5/11, Brian E Carpenter wrote: > > > > > > > Charlie, > > > > > > > > On 2011-08-06 08:48, Charles E. Perkins wrote: > > > >> > > > >> Hello Andrew, > > > >> > > > >> On 8/5/2011 10:44 AM, Andrew Sullivan wrote: > > > >> > > > >>> On Thu, Aug 04, 2011 at 11:56:10AM -0700, Charles E. Perkins > wrote: > > > >>> > > > >>>> I really think that NAT[v4-->v6] is important as > > > >>>> a perhaps crucial part of the transition story. > > > >>> > > > >>> I would like to see the argument for this. > > > >> > > > >> If we don't have NAT[v4-->v6], then IPv6-only > > > >> services are not going to be available to most > > > >> of the Internet for a really long time. > > > >> > > > >> Which, I reckon, means that all services are going > > > >> to be either IPv4-only or dual-stack for a really > > > >> long time. > > > > > > > > Correct. I've regarded that as a given for some years now. > > > > I wouldn't put any of my own money into an application service > > > > provider who proposed to go IPv6-only in the near future. > > > > > > > >> It seems to me that requiring all services to > > > >> have IPv4 addresses is directly counter to the > > > >> general IETF theme of promoting IPv6 transition. > > > > > > > > I try to avoid the word "transition" and focus on co-existence. > > > > Also, the "universal deployment of IPv6" does not imply > > > > "deployment of IPv6-only services". So I'm not sure that this > > > > is a current goal for the IETF. It seems like something that > > > > lies quite some years in the future. > > > > > > Seems to me, then, we can comfortably postpone serious work on > NAT[v4-- > > > >v6] until (and if) we find we really need it... > > > > Fully agree. +1 > > > > In last year, we had some mobile providers told us they might have > IPv6-only mobile devices. But now, the situation has changed. We are > told all major mobile OSes support or plan to support, in short time > scale, dual stack; and at their experimental measurement, running dual > stack is not that computational consumption as they original thought. > Without real traffic, keeping dual stack on is almost negligible. As > long as there have no duplicated traffic for the same application, > dual stack is not expensive than IPv4/Ipv6 single stack. So, the > conclusion is even mobile devices would be dual stack. There won't be > IPv6-only devices for a long while. > > > > My understanding is different. > > In fact, I am a mobile operator that has beta ipv6-only capable > devices that will be launched soon. > > Furthermore, dual-stack in pre-release 9 networks is 2x the pdp , > which generally translates to 2x the cost (lincenses, signalling, > mobility events, session setup, authetication...). This case is > different in LTE, but the LTE ramp rate is still very very small > compared to gsm and umts.... and dual stack fundamentally does not > solve private and public address exhaustion that most mobile providers > are currently challenged with, since dual stack requires the ipv4 > address that are ....exhausted.... so if ipv4 exhaustion is a tactical > business problem, dual stack is not the answer... and yes, the devices > are in the pipeline > +1. xing --------------030208040509060004020608 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 于 2011/8/8 9:54, Cameron Byrne 写道:


On Aug 7, 2011 6:35 PM, "Jiangsheng" <jiangsheng@huawei.com> wrote:
>
> > Brian, et al.,
> >
> > On Aug 5, 2011, at 5:25 PM 8/5/11, Brian E Carpenter wrote:
> >
> > > Charlie,
> > >
> > > On 2011-08-06 08:48, Charles E. Perkins wrote:
> > >>
> > >> Hello Andrew,
> > >>
> > >> On 8/5/2011 10:44 AM, Andrew Sullivan wrote:
> > >>
> > >>> On Thu, Aug 04, 2011 at 11:56:10AM -0700, Charles E. Perkins wrote:
> > >>>
> > >>>> I really think that NAT[v4-->v6] is important as
> > >>>> a perhaps crucial part of the transition story.
> > >>>
> > >>> I would like to see the argument for this.
> > >>
> > >> If we don't have NAT[v4-->v6], then IPv6-only
> > >> services are not going to be available to most
> > >> of the Internet for a really long time.
> > >>
> > >> Which, I reckon, means that all services are going
> > >> to be either IPv4-only or dual-stack for a really
> > >> long time.
> > >
> > > Correct. I've regarded that as a given for some years now.
> > > I wouldn't put any of my own money into an application service
> > > provider who proposed to go IPv6-only in the near future.
> > >
> > >> It seems to me that requiring all services to
> > >> have IPv4 addresses is directly counter to the
> > >> general IETF theme of promoting IPv6 transition.
> > >
> > > I try to avoid the word "transition" and focus on co-existence.
> > > Also, the "universal deployment of IPv6" does not imply
> > > "deployment of IPv6-only services". So I'm not sure that this
> > > is a current goal for the IETF. It seems like something that
> > > lies quite some years in the future.
> >
> > Seems to me, then, we can comfortably postpone serious work on NAT[v4--
> > >v6] until (and if) we find we really need it...
>
> Fully agree. +1
>
> In last year, we had some mobile providers told us they might have IPv6-only mobile devices. But now, the situation has changed. We are told all major mobile OSes support or plan to support, in short time scale, dual stack; and at their experimental measurement, running dual stack is not that computational consumption as they original thought. Without real traffic, keeping dual stack on is almost negligible. As long as there have no duplicated traffic for the same application, dual stack is not expensive than IPv4/Ipv6 single stack. So, the conclusion is even mobile devices would be dual stack. There won't be IPv6-only devices for a long while.
>

My understanding is different.

In fact, I am a mobile operator that has beta ipv6-only capable devices that will be launched soon.

Furthermore, dual-stack in pre-release 9 networks is 2x the pdp , which generally translates to 2x the cost (lincenses, signalling, mobility events, session setup, authetication...). This case is different in LTE, but the LTE ramp rate is still very very small compared to gsm and umts.... and dual stack fundamentally does not solve private and public address exhaustion that most mobile providers are currently challenged with, since dual stack requires the ipv4 address that are ....exhausted.... so if ipv4 exhaustion is a tactical business problem, dual stack is not the answer... and yes, the devices are in the pipeline


+1.

xing



--------------030208040509060004020608-- From simon.perreault@viagenie.ca Thu Aug 11 06:21: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 28B7921F87DA for ; Thu, 11 Aug 2011 06:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.237 X-Spam-Level: X-Spam-Status: No, score=-2.237 tagged_above=-999 required=5 tests=[AWL=-0.163, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, SARE_SUB_OBFU_Q1=0.227] 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 fVUEAn+M+yIP for ; Thu, 11 Aug 2011 06:21:24 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id E0D6C21F881C for ; Thu, 11 Aug 2011 06:21:23 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:21d:60ff:fed7:e732]) by jazz.viagenie.ca (Postfix) with ESMTPSA id C9C4421C75; Thu, 11 Aug 2011 09:21:57 -0400 (EDT) Message-ID: <4E43D775.4060009@viagenie.ca> Date: Thu, 11 Aug 2011 09:21:57 -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: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= References: <4E3BDE80.500@viagenie.ca> <0ED9A8FE-FDFA-45E1-A2CD-F3435F3877B5@free.fr> In-Reply-To: <0ED9A8FE-FDFA-45E1-A2CD-F3435F3877B5@free.fr> X-Enigmail-Version: 1.2.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] [CGN reqs] Adjustments to logging section 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, 11 Aug 2011 13:21:25 -0000 On 2011-08-11 03:24, Rémi Després wrote: > If the algorithm used for port-set generation is stateless, as > proposed with 4rd, log entries don't need to contain "parameters and > algorithm used for the port set generation". I understand your point, but stateless solutions such as 4rd are out of scope for this document. We're talking about CGN logging. There really is no CGN in 4rd. Just a layer 4 router. And as I understand it, 4rd allocations could be logged directly by the DHCP server. 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 mohamed.boucadair@orange-ftgroup.com Thu Aug 11 07:54: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 3258221F87FA for ; Thu, 11 Aug 2011 07:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[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 k2ZEaDdEUgZl for ; Thu, 11 Aug 2011 07:54:19 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id DAAAD21F8A97 for ; Thu, 11 Aug 2011 07:54:15 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 5681918C743; Thu, 11 Aug 2011 16:54:49 +0200 (CEST) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 3A4DA4C091; Thu, 11 Aug 2011 16:54:49 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Thu, 11 Aug 2011 16:54:48 +0200 From: To: Paco Cortes , "rpenno@juniper.net" , "tasaxena@cisco.com" , "ssenthil@cisco.com" Date: Thu, 11 Aug 2011 16:54:47 +0200 Thread-Topic: [BEHAVE] I-D Action: draft-ietf-behave-64-analysis-04.txt Thread-Index: AcxXS1LT2u/a8HcHRcOOBuVTTY6PuQA6sXjQ Message-ID: <94C682931C08B048B7A8645303FDC9F33E54A6291F@PUEXCB1B.nanterre.francetelecom.fr> References: <20110809133725.20875.30137.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" 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.8.11.142414 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-64-analysis-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: Thu, 11 Aug 2011 14:54:20 -0000 Dear Paco, Thank you for catching this. This is indeed a typo in the table. FWIW, in p= age 4 we mentioned: " 3. Need for the NAT64-capable device to act as proxy for correspondent node when IPv6 node is mobile, with consequent restrictions on mobility (Section 2.7 of [RFC4966]). Analysis: This is not specific to NAT64..." Is there any harm if we correct this typo in the next iteration of the draf= t (e.g., after the IETF LC)? Thanks. Cheers, Med -----Message d'origine----- De : Paco Cortes [mailto:pacosaddress@googlemail.com]=20 Envoy=E9 : mercredi 10 ao=FBt 2011 12:50 =C0 : rpenno@juniper.net; tasaxena@cisco.com; BOUCADAIR Mohamed OLNC/NAD/TI= P; ssenthil@cisco.com Cc : behave@ietf.org Objet : Re: [BEHAVE] I-D Action: draft-ietf-behave-64-analysis-04.txt Hi, In Table 1, the "proxy correspondent node for MIPv6" issue should be classified as NOT NAT-PT specific, shouldn't it? Is it a typo that you wrote "yes" in the corresponding cell, or is there a dependency that I am missing? +---------------+----------+---------+----------+---------+---------+ | Proxy | Yes | Yes | No | No | No | | correspondent | | | | | | | node for | | | | | | | MIPv6 | | | | | | +---------------+----------+---------+----------+---------+---------+ br, Paco 2011/8/9 : > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. This draft is a work item of the Behavior Engineering for Hindrance = Avoidance Working Group of the IETF. > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Analysis of Stateful 64 Transl= ation > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Reinaldo Penno > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Tarun Saxena > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Mohamed Boucadair > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Senthil Sivakumar > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-behave-64-analysis-04= .txt > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 15 > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-08-09 > > =A0 Due to specific problems, NAT-PT was deprecated by the IETF as a > =A0 mechanism to perform IPv6-IPv4 translation. =A0Since then, new effort= s > =A0 have been undertaken within IETF to standardize alternative > =A0 mechanisms to perform IPv6-IPv4 translation. =A0This document evaluat= es > =A0 how the new stateful translation mechanisms avoid the problems that > =A0 caused the IETF to deprecate NAT-PT. > > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-behave-64-analysis-04.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-64-analysis-04.txt > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From pacosaddress@googlemail.com Thu Aug 11 08:10:19 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECF6821F8749 for ; Thu, 11 Aug 2011 08:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.733 X-Spam-Level: X-Spam-Status: No, score=-2.733 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 8wrRnccgDPoe for ; Thu, 11 Aug 2011 08:10:19 -0700 (PDT) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by ietfa.amsl.com (Postfix) with ESMTP id 03E2921F8742 for ; Thu, 11 Aug 2011 08:10:18 -0700 (PDT) Received: by iye1 with SMTP id 1so168418iye.27 for ; Thu, 11 Aug 2011 08:10:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Jf4CinZe9muzsDSy3c3xqmFxDZC+vHatZWgiqtczRH8=; b=a36atcm/74iWTCIYNt2VrXZXOz1/pCUjSivkU48E0rUv0v8oxBERk69xRPx2NQOE6f 5DN5RbKI/HpBhQ8qotJ6xhpGLIPUbPlFYR07hf6OmXxS3IXhMazAp2zOj0KfrWhj/Ac8 U24NpZi/LXROet3d5qSYddzvUqWI+wz8+muMM= MIME-Version: 1.0 Received: by 10.231.111.167 with SMTP id s39mr13849354ibp.65.1313075433381; Thu, 11 Aug 2011 08:10:33 -0700 (PDT) Received: by 10.231.146.199 with HTTP; Thu, 11 Aug 2011 08:10:33 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F33E54A6291F@PUEXCB1B.nanterre.francetelecom.fr> References: <20110809133725.20875.30137.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F33E54A6291F@PUEXCB1B.nanterre.francetelecom.fr> Date: Thu, 11 Aug 2011 17:10:33 +0200 Message-ID: From: Paco Cortes To: mohamed.boucadair@orange-ftgroup.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "tasaxena@cisco.com" , "behave@ietf.org" Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-64-analysis-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: Thu, 11 Aug 2011 15:10:20 -0000 No harm :-) 2011/8/11 : > Dear Paco, > > Thank you for catching this. This is indeed a typo in the table. FWIW, in= page 4 we mentioned: > > " =A0 3. =A0Need for the NAT64-capable device to act as proxy for > =A0 =A0 =A0 correspondent node when IPv6 node is mobile, with consequent > =A0 =A0 =A0 restrictions on mobility (Section 2.7 of [RFC4966]). > > =A0 =A0 =A0 =A0 =A0Analysis: This is not specific to NAT64..." > > Is there any harm if we correct this typo in the next iteration of the dr= aft (e.g., after the IETF LC)? > > Thanks. > Cheers, > Med > > > -----Message d'origine----- > De : Paco Cortes [mailto:pacosaddress@googlemail.com] > Envoy=E9 : mercredi 10 ao=FBt 2011 12:50 > =C0 : rpenno@juniper.net; tasaxena@cisco.com; BOUCADAIR Mohamed OLNC/NAD/= TIP; ssenthil@cisco.com > Cc : behave@ietf.org > Objet : Re: [BEHAVE] I-D Action: draft-ietf-behave-64-analysis-04.txt > > Hi, > > In Table 1, the "proxy correspondent node for MIPv6" issue should be > classified as NOT NAT-PT specific, shouldn't it? > Is it a typo that you wrote "yes" in the corresponding cell, or is > there a dependency that I am missing? > > =A0 +---------------+----------+---------+----------+---------+---------+ > =A0 | =A0 =A0 Proxy =A0 =A0 | =A0 =A0Yes =A0 | =A0 Yes =A0 | =A0 =A0No = =A0 =A0| =A0 =A0No =A0 | =A0 =A0No =A0 | > =A0 | correspondent | =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 | =A0 =A0 =A0 = =A0 =A0| =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 | > =A0 | =A0 =A0node for =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 MIPv6 =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 +---------------+----------+---------+----------+---------+---------+ > > br, > =A0Paco > > > 2011/8/9 =A0: >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. This draft is a work item of the Behavior Engineering for Hindrance= Avoidance Working Group of the IETF. >> >> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Analysis of Stateful 64 Trans= lation >> =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Reinaldo Penno >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Tarun Saxena >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Mohamed Boucadair >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Senthil Sivakumar >> =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-behave-64-analysis-0= 4.txt >> =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 15 >> =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-08-09 >> >> =A0 Due to specific problems, NAT-PT was deprecated by the IETF as a >> =A0 mechanism to perform IPv6-IPv4 translation. =A0Since then, new effor= ts >> =A0 have been undertaken within IETF to standardize alternative >> =A0 mechanisms to perform IPv6-IPv4 translation. =A0This document evalua= tes >> =A0 how the new stateful translation mechanisms avoid the problems that >> =A0 caused the IETF to deprecate NAT-PT. >> >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-behave-64-analysis-04.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-64-analysis-04.txt >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> > From behcetsarikaya@yahoo.com Thu Aug 11 12:27: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 07D0A21F8B34 for ; Thu, 11 Aug 2011 12:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.588 X-Spam-Level: X-Spam-Status: No, score=-0.588 tagged_above=-999 required=5 tests=[AWL=-0.589, BAYES_50=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 W14cmome2cZV for ; Thu, 11 Aug 2011 12:27:38 -0700 (PDT) Received: from nm18-vm4.bullet.mail.ne1.yahoo.com (nm18-vm4.bullet.mail.ne1.yahoo.com [98.138.91.178]) by ietfa.amsl.com (Postfix) with SMTP id 6E68321F8B39 for ; Thu, 11 Aug 2011 12:27:37 -0700 (PDT) Received: from [98.138.90.50] by nm18.bullet.mail.ne1.yahoo.com with NNFMP; 11 Aug 2011 19:28:08 -0000 Received: from [98.138.89.248] by tm3.bullet.mail.ne1.yahoo.com with NNFMP; 11 Aug 2011 19:28:08 -0000 Received: from [127.0.0.1] by omp1040.mail.ne1.yahoo.com with NNFMP; 11 Aug 2011 19:28:08 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 736981.35451.bm@omp1040.mail.ne1.yahoo.com Received: (qmail 13383 invoked by uid 60001); 11 Aug 2011 19:28:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1313090887; bh=xRzlULJwCZKMjy06IzFTCs7iSeSjaKyXBIctDOEbnpg=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=xcMp0ukifutKOqFH83uwgWQAgxHG1f18Oq77Qx9XBbM4BWwilmxFWomwBdal8eQDw6lu7hZR2JYqVaBfPe71LDaDndD/84xGuNYdFTSxqBmHrhS9kQ6HeiZGmIVeiEXH5O12+Aa1PMk6slO1bfAC/06LRFTQUVq7gfElqFwCGaA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=0GY1grS28TDM77sqCRg1ktd+8XU5ejLKaJWnq52V6I0riP5YEsCq/cHs8QoZ3n6LTNf7rIyIK2hxPYfOIWKupFj66z0RB4ERze1sXu/eHyBYKRQlINewyMB2BGEoGGxCn7ooXVvAJdK7LHOC/ndIMTnjGaXDtGmTC/SHdEx/72U=; X-YMail-OSG: owITDTIVM1mSVL7iUaIAX6u6kEk45XiH8lLhDhy5m9b6NK4 TPRqh2RQoWnzN16.PPtpCHLQSTtQCpvn9zIlfHQHidvlyILPqBrf26YQmGlF Nca8eCvvCLFhIrb4hkS0zR3L9U7_4ibUxBSl7S4yZddb_Q69exhxHgy40F7E IuanbymvM4hlYPMPCsUAmljNHMMGX9ljXXnpX5uTDRzTdsL530MDB5fjGdG_ z2bGovFM0ySIPOgZpiq8aaAbV0OzLdfAU3l8zmZTaPWNqf3nqncUUMmJ6EDN _2Dzs4WXSnxTHKBBDf8c9Im2oSJl5LRh.CZGwWUy.EG5NbCcLrO63xsbtFHJ _iBgr9UXOv7m0BTneG3sXSxsCbD6nKxkvvPtWFJ_wFcSXRARx0CazaRnQ8A1 Xg9nbQ53sWc6YkavxHMiopI6oIxJ51x2uXdYRtBCe4OQ9k64dm21ThLv9eM_ axqdODB4- Received: from [50.58.7.243] by web111412.mail.gq1.yahoo.com via HTTP; Thu, 11 Aug 2011 12:28:07 PDT X-Mailer: YahooMailWebService/0.8.113.313619 References: <285AA91F41624C6B963A45FECC73F56E@davidPC> Message-ID: <1313090887.1692.YahooMailNeo@web111412.mail.gq1.yahoo.com> Date: Thu, 11 Aug 2011 12:28:07 -0700 (PDT) From: Behcet Sarikaya To: Cameron Byrne , David Harrington In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Closing the behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 19:27:39 -0000 > >I disagree that it should be closed and suggest that the nat464 (as described in pnat, 4v6, and bih) be properly named >nat464, generalized, +1 >and brought into this group, softwire is not the right place. It is a shame that nat464 has such a bad name that the concept has to be veiled in various other specs >Cb >_______________________________________________ >Behave mailing list >Behave@ietf.org >https://www.ietf.org/mailman/listinfo/behave > > > From behcetsarikaya@yahoo.com Thu Aug 11 12:52:11 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8255C21F8ABB for ; Thu, 11 Aug 2011 12:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.875 X-Spam-Level: X-Spam-Status: No, score=-1.875 tagged_above=-999 required=5 tests=[AWL=0.724, 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 TIqpB48Zn1wQ for ; Thu, 11 Aug 2011 12:52:10 -0700 (PDT) Received: from nm9.bullet.mail.sp2.yahoo.com (nm9.bullet.mail.sp2.yahoo.com [98.139.91.79]) by ietfa.amsl.com (Postfix) with SMTP id AB6D821F8AAA for ; Thu, 11 Aug 2011 12:52:10 -0700 (PDT) Received: from [98.139.91.61] by nm9.bullet.mail.sp2.yahoo.com with NNFMP; 11 Aug 2011 19:52:41 -0000 Received: from [98.139.91.6] by tm1.bullet.mail.sp2.yahoo.com with NNFMP; 11 Aug 2011 19:52:41 -0000 Received: from [127.0.0.1] by omp1006.mail.sp2.yahoo.com with NNFMP; 11 Aug 2011 19:52:41 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 6790.41778.bm@omp1006.mail.sp2.yahoo.com Received: (qmail 52200 invoked by uid 60001); 11 Aug 2011 19:52:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1313092360; bh=23xBZ76ofA5m2yrnaOHQqwSoqifHkdtuBWP6joZLdDA=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=NGCZ1a4ytLDSUGU7bcAcA5Lx93/mco8h6Lwg+Ww417Wmn6f8KfU75RwXp9hDWVgK58ie56GRgVV80z408sHOoQt0B7lsBH8pp/TxUzwoaiGdL3iQJZMe2Sse2nKOA5yxy+ORsoodeOCOdn9JdtrutnmW+NUWmzmN7rzdipJqLuY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=mwdejTi201gJggBiwJ5V1VQ8FNkgClKxMI0PHT1vBJvrMlkJRQ2T3SdRbKULsDTde8aQGDUbFsQBDLaKu3WRvmmIZ4XF9dtnzfysM3IgG92afPBPw2idEUPifmHOck79l6lue0VCVAKOKNOPEypuIITwbr9fnIXfCGz62zvMLyI=; X-YMail-OSG: tfLrtC8VM1nONji08mcZOKrZyoPOUcruMi41fOtWH1EBsKA DdHw.X6YXu7cukT.Ze0heLfFSubxwJYeMcvYY.1FG1WmsG3z29IplzgyLBs1 gqzN5N2pctQUXp80XwckbB_jWp8S7mVutIKCQk7xtMCEidyiHazYFXdGQwJO M.N4wXhK3Okn5eLfTV5Agqf98qaWAbCBfhdJhw5EDgXO0UGmze0ilbzCbURY KhBamtjHbnUKsjMwHGFkXnLERKAIqAnAasoHGoMTRT9mmOCmOq3tPhf6B6sO _bbTFuxt3Afgd2khvMe9LUkz9AmhjkXeJ4Zlrl444.h91rTp7Q8s6Fyfv.fi IpYVvxKII5p13SyFcrCot4BsYryfGYHuwhCbRB0bRPOgJg_F971kU.2EB3bJ lVhKTp.x2YciDxOLRTjka.bf4P6Rqju.kEsJY6MmXosM9sQ0mTWJmlxhE68k r52WlWN8- Received: from [50.58.7.243] by web111416.mail.gq1.yahoo.com via HTTP; Thu, 11 Aug 2011 12:52:40 PDT X-Mailer: YahooMailWebService/0.8.113.313619 References: <285AA91F41624C6B963A45FECC73F56E@davidPC> <4E3AEB4A.8080202@wichorus.com> <20110805174442.GR49271@shinkuro.com> <4E3C5734.6000009@wichorus.com> <4E3C5FBE.4090904@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B92012282A2@SZXEML506-MBS.china.huawei.com> Message-ID: <1313092360.51048.YahooMailNeo@web111416.mail.gq1.yahoo.com> Date: Thu, 11 Aug 2011 12:52:40 -0700 (PDT) From: Behcet Sarikaya To: Jiangsheng In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B92012282A2@SZXEML506-MBS.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Closing the behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 19:52:11 -0000 =0A=0AHi Sheng,=0A=A0 I think here the intent was more on NAT46 or 4rd. Not= on NAT64.=0A=0ARegards,=0A=0ABehcet=0A=0A>> Brian, et al.,=0A>> =0A>> On= Aug 5, 2011, at 5:25 PM 8/5/11, Brian E Carpenter wrote:=0A>> =0A>> > Cha= rlie,=0A>> >=0A>> > On 2011-08-06 08:48, Charles E. Perkins wrote:=0A>> = >>=0A>> >> Hello Andrew,=0A>> >>=0A>> >> On 8/5/2011 10:44 AM, Andrew Su= llivan wrote:=0A>> >>=0A>> >>> On Thu, Aug 04, 2011 at 11:56:10AM -0700, = Charles E. Perkins =0A> wrote:=0A>> >>>=0A>> >>>> I really think that NAT= [v4-->v6] is important as=0A>> >>>> a perhaps crucial part of the transiti= on story.=0A>> >>>=0A>> >>> I would like to see the argument for this.=0A= >> >>=0A>> >> If we don't have NAT[v4-->v6], then IPv6-only=0A>> >> serv= ices are not going to be available to most=0A>> >> of the Internet for a r= eally long time.=0A>> >>=0A>> >> Which, I reckon, means that all services= are going=0A>> >> to be either IPv4-only or dual-stack for a really=0A>> = >> long time.=0A>> >=0A>> > Correct. I've regarded that as a given for s= ome years now.=0A>> > I wouldn't put any of my own money into an applicati= on service=0A>> > provider who proposed to go IPv6-only in the near future= .=0A>> >=0A>> >> It seems to me that requiring all services to=0A>> >> h= ave IPv4 addresses is directly counter to the=0A>> >> general IETF theme o= f promoting IPv6 transition.=0A>> >=0A>> > I try to avoid the word "trans= ition" and focus on =0A> co-existence.=0A>> > Also, the "universal deploym= ent of IPv6" does not imply=0A>> > "deployment of IPv6-only services". So = I'm not sure that =0A> this=0A>> > is a current goal for the IETF. It seem= s like something that=0A>> > lies quite some years in the future.=0A>> =0A= >> Seems to me, then, we can comfortably postpone serious work on NAT[v4--= =0A>> >v6] until (and if) we find we really need it...=0A> =0A> Fully agre= e. +1=0A> =0A> In last year, we had some mobile providers told us they migh= t have IPv6-only =0A> mobile devices. But now, the situation has changed. W= e are told all major mobile =0A> OSes support or plan to support, in short = time scale, dual stack; and at their =0A> experimental measurement, running= dual stack is not that computational =0A> consumption as they original tho= ught. Without real traffic, keeping dual stack =0A> on is almost negligible= . As long as there have no duplicated traffic for the =0A> same application= , dual stack is not expensive than IPv4/Ipv6 single stack. So, =0A> the con= clusion is even mobile devices would be dual stack. There won't be =0A> IPv= 6-only devices for a long while.=0A> =0A> Sheng=0A> =0A>> - Ralph=0A>> =0A= >> >=0A>> > Regards=0A>> >=0A>> >=A0 Brian=0A>> >=0A>> >> Perhaps in= stead you meant that there are not any=0A>> >> credible possibilities for = NAT[v4-->v6].=A0 I am=0A>> >> willing to agree that as far as I understand= it=0A>> >> the alternatives (as of now) have problems of either=0A>> >> = scalability or maybe vulnerability to DoS attacks.=0A>> >> I think these a= re problems that can be solved,=0A>> >> and they would be solved faster in= a working group.=0A>> >>=0A>> >> Looked at another way, if [behave] shut= s down=0A>> >> without working on NAT[v4-->v6], then it can be=0A>> >> se= en as sending a strong message that the IETF=0A>> >> believes that all ser= vices and websites really need=0A>> >> to maintain IPv4 addressability ad = infinitum=0A>> >> [or at least all commercially viable ones].=0A>> >>=0A>= > >> Regards,=0A>> >> Charlie P.=0A>> >>=0A>> >> ______________________= _________________________=0A>> >> Behave mailing list=0A>> >> Behave@ietf= .org=0A>> >> https://www.ietf.org/mailman/listinfo/behave=0A>> >>=0A>> >= _______________________________________________=0A>> > Behave mailing lis= t=0A>> > Behave@ietf.org=0A>> > https://www.ietf.org/mailman/listinfo/beh= ave=0A>> =0A>> _______________________________________________=0A>> Behav= e mailing list=0A>> Behave@ietf.org=0A>> https://www.ietf.org/mailman/lis= tinfo/behave=0A> _______________________________________________=0A> Behave= mailing list=0A> Behave@ietf.org=0A> https://www.ietf.org/mailman/listinfo= /behave=0A> From linfeng.john.zheng@gmail.com Thu Aug 11 20:13: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 0C1E821F8596 for ; Thu, 11 Aug 2011 20:13:25 -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 y1u4e-0OlfMi for ; Thu, 11 Aug 2011 20:13:24 -0700 (PDT) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by ietfa.amsl.com (Postfix) with ESMTP id EE20E21F856A for ; Thu, 11 Aug 2011 20:13:23 -0700 (PDT) Received: by iye1 with SMTP id 1so1113067iye.27 for ; Thu, 11 Aug 2011 20:13:49 -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=DcuhaKXZoMG2dUSdX5wCP/1g0KVbeHCXXyY23pvH1Mg=; b=aQWnQ54ytlQFfrlmPo1SCyPNNgXKg9VCwx1MDoXwtoB4tWxygzjZY5D6wmLxvbIDE/ rKDf+wu4XEyR439Dqt9mlyh63oQppJIJJ7/0xpwvF5n2R5JGLbWnW1wNrdEJUxyAZ1h+ BXVcfVQM4OqDRFBvC3PHmrs3V+UYa0Me2Sk+o= MIME-Version: 1.0 Received: by 10.231.118.170 with SMTP id v42mr874049ibq.72.1313118829683; Thu, 11 Aug 2011 20:13:49 -0700 (PDT) Received: by 10.231.53.79 with HTTP; Thu, 11 Aug 2011 20:13:49 -0700 (PDT) Date: Fri, 12 Aug 2011 11:13:49 +0800 Message-ID: From: Linfeng Zheng To: behave@ietf.org Content-Type: multipart/alternative; boundary=0016369c887e6423b804aa464d5b Subject: Re: [BEHAVE] Closing the behave WG 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, 12 Aug 2011 03:13:25 -0000 --0016369c887e6423b804aa464d5b Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Re: [BEHAVE] Closing the behave WG ------------------------------ - *To*: Cameron Byrne >, David Harrington > - *Subject*: Re: [BEHAVE] Closing the behave WG - *From*: Behcet Sarikaya > - *Date*: Thu, 11 Aug 2011 12:28:07 -0700 (PDT) - *Cc*: "behave at ietf.org " > - *Delivered-to*: behave at ietfa.amsl.com - *Dkim-signature*: v=3D1; a=3Drsa-sha256; c=3Drelaxed/relaxed; d=3Dyaho= o.com; s=3Ds1024; t=3D1313090887; bh=3DxRzlULJwCZKMjy06IzFTCs7iSeSjaKyXBIctDOEb= npg=3D; h=3DX-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-= To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=3DxcMp0ukifutKOqFH83uwgWQAgxHG1f18Oq77Qx9XBbM4BWwilmxFWomwBdal8eQDw6lu= 7hZR2JYqVaBfPe71LDaDndD/84xGuNYdFTSxqBmHrhS9kQ6HeiZGmIVeiEXH5O12+Aa1PMk6slO= 1bfAC/06LRFTQUVq7gfElqFwCGaA=3D - *Domainkey-signature*: a=3Drsa-sha1; q=3Ddns; c=3Dnofws; s=3Ds1024; d= =3Dyahoo.com; h=3DX-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-= To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=3D0GY1grS28TDM77sqCRg1ktd+8XU5ejLKaJWnq52V6I0riP5YEsCq/cHs8QoZ3n6LTNf7= rIyIK2hxPYfOIWKupFj66z0RB4ERze1sXu/eHyBYKRQlINewyMB2BGEoGGxCn7ooXVvAJdK7LHO= C/ndIMTnjGaXDtGmTC/SHdEx/72U=3D; - *In-reply-to*: > - *List-archive*: - *List-help*: > - *List-id*: mailing list of BEHAVE IETF WG - *List-post*: > - *List-subscribe*: , < mailto:behave-request@ietf.org?subject=3Dsubscribe> - *List-unsubscribe*: , < mailto:behave-request@ietf.org?subject=3Dunsubscribe> - *References*: <285AA91F41624C6B963A45FECC73F56E at davidPC<285AA91F41624C6B963A45FECC73F56E@DOMAIN.HIDDEN>> > - *Reply-to*: Behcet Sarikaya > ------------------------------ >> >>I disagree that it should be closed and suggest that the nat464 (as descr= ibed in pnat, 4v6, and bih) be properly named >nat464, generalized, >+1 + my 0.01 >>and brought into this group, softwire is not the right place. It is a sha= me that nat464 has such a bad name that the concept has to be veiled in var= ious other specs >>Cb >>_______________________________________________ >>Behave mailing list >>Behave at ietf.org >>https://www.ietf.org/mailman/listinfo/behave >> >> >> =D6=A3=C1=D6=B7=E5 John Linfeng Zheng CCIE#8670 =B5=E7=BB=B0=A3=A8Tel): 86-25-8577-1689 =CA=D6=BB=FA=A3=A8Mobile): 15195762065 --0016369c887e6423b804aa464d5b Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable

Re: [BEHAVE] Closing the behave WG

>>
>>I disagree that it should be closed and suggest that the nat464 (as=
 described in pnat, 4v6, and bih) be properly named >nat464, generalized=
,=20


>+1

+ my 0.01

>>and brought into this group, softwire is not the right place. It is=
 a shame that nat464 has such a bad name that the concept has to be veiled =
in various other specs
>>Cb
>>_______________________________________________
>>Behave mailing list
>>Behave at ietf.org
>>https://www.ietf.org/mailman/listinfo/behave
>>
>>
>>

 
 
=D6=A3=C1=D6=B7=E5 John Linfeng Zheng   CCIE#8670
=B5=E7=BB=B0=A3=A8Tel): 86-25-8577-1689
=CA=D6=BB=FA=A3=A8Mobile): 15195762065

--0016369c887e6423b804aa464d5b-- From charliep@tellabs.com Thu Aug 11 10:56:11 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF495E8008 for ; Thu, 11 Aug 2011 10:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.906 X-Spam-Level: X-Spam-Status: No, score=-3.906 tagged_above=-999 required=5 tests=[AWL=-0.607, BAYES_00=-2.599, 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 MwnwVAlkhJfe for ; Thu, 11 Aug 2011 10:56:11 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id EDA335E8002 for ; Thu, 11 Aug 2011 10:56:10 -0700 (PDT) Received: from mail87-ch1-R.bigfish.com (216.32.181.170) by CH1EHSOBE006.bigfish.com (10.43.70.56) with Microsoft SMTP Server id 14.1.225.22; Thu, 11 Aug 2011 17:56:45 +0000 Received: from mail87-ch1 (localhost.localdomain [127.0.0.1]) by mail87-ch1-R.bigfish.com (Postfix) with ESMTP id 50835C404E9; Thu, 11 Aug 2011 17:56:45 +0000 (UTC) X-SpamScore: -8 X-BigFish: VPS-8(zzc89bh8fcdK1432Nzz1202hzzz2ei2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:138.111.41.192; KIP:(null); UIP:(null); IPVD:NLI; H:usdt1wmspedge01.tellabs-west.tellabsinc.net; RD:tlab-138-111-41-192.tellabs.com; EFVD:NLI Received-SPF: neutral (mail87-ch1: 138.111.41.192 is neither permitted nor denied by domain of tellabs.com) client-ip=138.111.41.192; envelope-from=charliep@tellabs.com; helo=usdt1wmspedge01.tellabs-west.tellabsinc.net ; llabsinc.net ; Received: from mail87-ch1 (localhost.localdomain [127.0.0.1]) by mail87-ch1 (MessageSwitch) id 13130853801262_11519; Thu, 11 Aug 2011 17:56:20 +0000 (UTC) Received: from CH1EHSMHS012.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.253]) by mail87-ch1.bigfish.com (Postfix) with ESMTP id 75535158021D; Thu, 11 Aug 2011 17:55:52 +0000 (UTC) Received: from usdt1wmspedge01.tellabs-west.tellabsinc.net (138.111.41.192) by CH1EHSMHS012.bigfish.com (10.43.70.12) with Microsoft SMTP Server (TLS) id 14.1.225.22; Thu, 11 Aug 2011 17:55:51 +0000 Received: from usnvwwmspht01.tellabs-west.tellabsinc.net (172.23.211.69) by usdt1wmspedge01.tellabs-west.tellabsinc.net (172.28.10.104) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 11 Aug 2011 12:55:49 -0500 Received: from EX-WEST.tellabs-west.tellabsinc.net ([172.23.211.73]) by usnvwwmspht01.tellabs-west.tellabsinc.net ([172.23.211.69]) with mapi; Thu, 11 Aug 2011 12:55:48 -0500 From: "Perkins, Charles" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Date: Thu, 11 Aug 2011 12:55:04 -0500 Thread-Topic: [BEHAVE] Closing the behave WG Thread-Index: AcxYM9tOv2H/Oce+RCKwBx/toCjssQAG/FQG Message-ID: References: <285AA91F41624C6B963A45FECC73F56E@davidPC><4E3AEB4A.8080202@wichorus.com> <20110805174442.GR49271@shinkuro.com><4E3C5734.6000009@wichorus.com> <20110805212447.GF51956@shinkuro, <953315D6-5ABE-49FE-9020-BAF4DE91C089@free.fr> In-Reply-To: <953315D6-5ABE-49FE-9020-BAF4DE91C089@free.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: tellabs.com X-Mailman-Approved-At: Fri, 12 Aug 2011 09:20:58 -0700 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Closing the behave WG 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, 11 Aug 2011 17:56:11 -0000 Hello R=E9mi, I think you are in agreement with me on all points below -- please take a look... > From: R=E9mi Despr=E9s [remi.despres@free.fr] > Le 8 ao=FBt 2011 =E0 18:37, Charles E. Perkins a =E9crit : >> Put simply, if someone has a website or service, and they want >> it to be available to the Internet, it _HAS_ to be addressable >> by IPv4 right now. And this situation will persist until either: >> - NATv4v6 exists, or >> - the Internet is predominantly IPv6 > > This isn't really true because: > - Dual-stack routing offers IPv6 reachability without damaging IPv4 reach= ability. =3D=3D> destination IS addressable by IPv4. > - There are tunneling solutions that maintain IPv4 reachability across IP= v6-only routing networks without resorting to translation. =3D=3D> destination IS addressable by IPv4. > The point on which we agree, I suppose, is: > "IPv4 reachability has to be preserved as long as IPv4 traffic hasn't pra= ctically disappeared, being advantageously replaced by IPv6 traffic. =3D=3D> destination IS addressable by IPv4. Perhaps you misunderstood what I was trying to say? My point is that failing to provide NATv4->v6 practically requires all websites, services and peer-to-peer communications to maintain IPv4 addressability. That does NOT help to move the Internet to IPv6, and in fact significantly reduces IPv6's ability to solve the problem of IPv4 address exhaustion. Regards, Charlie P. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From iesg-secretary@ietf.org Mon Aug 15 10:53:31 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B16421F8C70; Mon, 15 Aug 2011 10:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, 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 p7Z5QMDpD-YI; Mon, 15 Aug 2011 10:53:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0E0F21F8C72; Mon, 15 Aug 2011 10:53:30 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.58 Message-ID: <20110815175330.2555.88391.idtracker@ietfa.amsl.com> Date: Mon, 15 Aug 2011 10:53:30 -0700 Cc: behave mailing list , behave chair , RFC Editor Subject: [BEHAVE] Protocol Action: 'An FTP ALG for IPv6-to-IPv4 translation' to Proposed Standard (draft-ietf-behave-ftp64-12.txt) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 17:53:31 -0000 The IESG has approved the following document: - 'An FTP ALG for IPv6-to-IPv4 translation' (draft-ietf-behave-ftp64-12.txt) as a Proposed Standard This document is the product of the Behavior Engineering for Hindrance Avoidance Working Group. The IESG contact persons are David Harrington and Wesley Eddy. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-behave-ftp64/ Technical Summary This document describes middlebox behavior to reduce the problem of IPv6 FTP clients connecting to IPv4 FTP servers on the Internet. Working Group Summary There was controversy around requirements for already- deployed FTP clients and FTP servers. This text has been removed and will appear in a separate document. IPR has been disclosed and announced to the mailing list, https://datatracker.ietf.org/ipr/search/?option=document_search&document_search=draft-ietf-behave-ftp64 and there has been no subsequent WG discussion about this IPR disclosure. Document Quality No existing implementations have been announced, but several vendors are actively implementing the specification. Reviewers are listed in the document's contributors section. No expert reviews were needed. Personnel Dan Wing, dwing@cisco.com is the Document Shepherd for this document. David Harrington, ietfdbh@comcast.net is the Responsible Area Director. The document doesn't require IANA experts RFC Editor Note #1) expand ALG in the title: Application Layer Gateway. #2) Section 4 includes: As such, it is recommended to update FTP clients and servers as required for IPv6-to-IPv4 translation support where possible, to allow proper operation of the FTP protocol without the need for ALGs. r/recommended/RECOMMENDED? #3) Section 5: missing right parenthesis: ([RFC4217] #4) needs normative reference for UTF-8. From charliep@wichorus.com Mon Aug 15 14:53: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 0A9C811E80DB for ; Mon, 15 Aug 2011 14:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 KdkTKxhKLIab for ; Mon, 15 Aug 2011 14:53:36 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id 53FA711E80C4 for ; Mon, 15 Aug 2011 14:53:35 -0700 (PDT) Received: from [138.111.58.2] (helo=[172.17.96.89]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Qt56x-00063W-Ee; Mon, 15 Aug 2011 17:54:19 -0400 Message-ID: <4E499586.3010205@wichorus.com> Date: Mon, 15 Aug 2011 14:54:14 -0700 From: "Charles E. Perkins" Organization: WiChorus Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= References: <285AA91F41624C6B963A45FECC73F56E@davidPC><4E3AEB4A.8080202@wichorus.com> <20110805174442.GR49271@shinkuro.com><4E3C5734.6000009@wichorus.com> <20110805212447.GF51956@shinkuro, <953315D6-5ABE-49FE-9020-BAF4DE91C089@free.fr> <069A3E16-41C6-4D24-B9C2-DD7E9C5F5D40@free.fr> In-Reply-To: <069A3E16-41C6-4D24-B9C2-DD7E9C5F5D40@free.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad862e19285460cc3202c35ea78990517a75350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 138.111.58.2 Cc: behave@ietf.org Subject: Re: [BEHAVE] Closing the behave WG 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, 15 Aug 2011 21:53:37 -0000 Hello Rémi, On 8/12/2011 12:12 AM, Rémi Després wrote: > Le 11 août 2011 à 19:55, Perkins, Charles a écrit : > >> My point is that failing to provide NATv4->v6 >> practically requires all websites, services and >> peer-to-peer communications to maintain IPv4 >> addressability. > > What is needed is only to offer production quality IPv6 everywhere, > without changing IPv4 connectivity for what it is (with NAT's, and > NAT cascades, where shared addresses are unavoidable). > ......... > Web-service providers can then get rid of their IPv4 support, without > having ever NEEDED NAT's between IPv6 and IPv4. I agree that is a _feasible_ outcome. But, it does not seem to be happening very fast. Enabling IPv6-only services and websites will protect future businesses and netizens from the high(er) cost of IPv4 allocation and administration, and could play a significant role in accelerating your scenario. Of course I don't particularly love NAT, but I use it every day. The more ways we can encourage the deployment of IPv6-only nodes (of all sorts), the faster we'll get to where we need to go. > .... many are convinced that NAT64 + DNS64 + PCP > is better for them, and announce plans to deploy this combination. > But this doesn't justify that one NEEDS NATv4->v6 for IPv6 to be > generalized, with the end result that IPv4 traffic vanishes. The disappearance of IPv4 traffic is not at all relevant, and should not factor in the discussion. Regards, Charlie P. From ietfdbh@comcast.net Tue Aug 16 05:39: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 6665F21F8A4D for ; Tue, 16 Aug 2011 05:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 8JSBQXVs2GnX for ; Tue, 16 Aug 2011 05:39:25 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id A7D4421F89B8 for ; Tue, 16 Aug 2011 05:39:25 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta13.westchester.pa.mail.comcast.net with comcast id LzFJ1h0051wpRvQ5D0gEVW; Tue, 16 Aug 2011 12:40:14 +0000 Received: from davidPC ([67.189.235.106]) by omta18.westchester.pa.mail.comcast.net with comcast id M0gC1h0092JQnJT3e0gCQv; Tue, 16 Aug 2011 12:40:12 +0000 From: "David Harrington" To: "'behave mailing list'" References: <20110815175330.2555.88391.idtracker@ietfa.amsl.com> In-Reply-To: <20110815175330.2555.88391.idtracker@ietfa.amsl.com> Date: Tue, 16 Aug 2011 08:39:55 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-index: AcxbdFzoiTEFmTEESz+YqgYuufZ+9gAnQTJQ X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.17609 Cc: 'behave chair' Subject: Re: [BEHAVE] Protocol Action: 'An FTP ALG for IPv6-to-IPv4 translation' toProposed Standard (draft-ietf-behave-ftp64-12.txt) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 12:39:26 -0000 Congratulations on a job well done! dbh > -----Original Message----- > From: ietf-announce-bounces@ietf.org > [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG > Sent: Monday, August 15, 2011 1:54 PM > To: IETF-Announce > Cc: behave mailing list; behave chair; RFC Editor > Subject: Protocol Action: 'An FTP ALG for IPv6-to-IPv4 > translation' toProposed Standard (draft-ietf-behave-ftp64-12.txt) > > The IESG has approved the following document: > - 'An FTP ALG for IPv6-to-IPv4 translation' > (draft-ietf-behave-ftp64-12.txt) as a Proposed Standard > > This document is the product of the Behavior Engineering for Hindrance > Avoidance Working Group. > > The IESG contact persons are David Harrington and Wesley Eddy. > > A URL of this Internet Draft is: > http://datatracker.ietf.org/doc/draft-ietf-behave-ftp64/ > > > > > Technical Summary > > This document describes middlebox behavior to reduce the problem of > IPv6 FTP clients connecting to IPv4 FTP servers on the Internet. > > Working Group Summary > > There was controversy around requirements for already- > deployed FTP clients and FTP servers. This text has been removed and > will appear in a separate document. > > IPR has been disclosed and announced to the mailing list, > https://datatracker.ietf.org/ipr/search/?option=document_searc > h&document_search=draft-ietf-behave-ftp64 > and there has been no subsequent WG discussion about this IPR > disclosure. > > Document Quality > > No existing implementations have been announced, but several > vendors are actively implementing the specification. > Reviewers are listed in the document's contributors section. > No expert reviews were needed. > > Personnel > > Dan Wing, dwing@cisco.com is the Document Shepherd for this document. > David Harrington, ietfdbh@comcast.net is the Responsible Area > Director. > The document doesn't require IANA experts > > RFC Editor Note > > #1) expand ALG in the title: Application Layer Gateway. > #2) Section 4 includes: As such, it is recommended to update > FTP clients and servers as required for IPv6-to-IPv4 > translation support where possible, to allow proper operation > of the FTP protocol without the need for ALGs. > r/recommended/RECOMMENDED? > #3) Section 5: missing right parenthesis: ([RFC4217] > #4) needs normative reference for UTF-8. > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > From dwing@cisco.com Tue Aug 16 11:04:11 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CFE721F8B82; Tue, 16 Aug 2011 11:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.48 X-Spam-Level: X-Spam-Status: No, score=-103.48 tagged_above=-999 required=5 tests=[AWL=-0.881, 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 jNdNzNDpThHT; Tue, 16 Aug 2011 11:04:11 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 03BEC21F8B7C; Tue, 16 Aug 2011 11:04:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=967; q=dns/txt; s=iport; t=1313517900; x=1314727500; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=1mf9PlOeKRFekSLOYJCNGFRTq4taU6Te1vLmzfGKQ4U=; b=Eo0ef7rafmto3Ka+zSOzX4E8phILVVG5iE8EaV7GwL1W+Yuwiv1O4vk1 nRP4pH+ljGfSCsK+Jo6G1BlaDikpu+j0wmRU+2XLmDkk0VB/lm74T0jDW 3Q6rgiPF7wnQZlla89Hmp3Zero4+IiNYf2uHNsfqOksTQhciNpruDnSr1 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As8AAFuwSk6rRDoI/2dsb2JhbABBmGqBbI1pd4FAAQEBAQIBAQEBBQoBFxA0EAcBAwIJDwIEAQEoBxkOFQoJCAEBBAESCxeHTgSaJQGfKYZIBIdfnEg X-IronPort-AV: E=Sophos;i="4.68,234,1312156800"; d="scan'208";a="13652369" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-1.cisco.com with ESMTP; 16 Aug 2011 18:04:59 +0000 Received: from dwingWS (sjc-vpn2-166.cisco.com [10.21.112.166]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p7GI4xvm008472; Tue, 16 Aug 2011 18:04:59 GMT From: "Dan Wing" To: "'Tina TSOU'" , , References: In-Reply-To: Date: Tue, 16 Aug 2011 11:04:58 -0700 Message-ID: <16ee01cc5c3f$03193360$094b9a20$@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: AcxcO3jp3sKqYmkyRu68rHYQ8viICgAA2uyg Content-Language: en-us Subject: Re: [BEHAVE] [pcp] two users request same address and port 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, 16 Aug 2011 18:04:11 -0000 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Tina TSOU > Sent: Tuesday, August 16, 2011 10:40 AM > To: behave@ietf.org; pcp@ietf.org > Subject: [pcp] two users request same address and port > > Hi guys, > http://portforward.com/cports.htm > > If two end users using XBox request same IPv4 public external address > on CGN, and same port, what will happen? If the address and port is available for assignment to that user, the user will get it. Otherwise, the user won't. So in the case above, the first user will probably get the address and port and the second user won't. -d > The CGN still works with these > applications listed above in the website link. > > > > Best Regards, > Tina TSOU > http://tinatsou.weebly.com/contact.html > > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From Tina.Tsou.Zouting@huawei.com Tue Aug 16 10:39: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 A59BC11E80F5; Tue, 16 Aug 2011 10:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.057 X-Spam-Level: X-Spam-Status: No, score=-6.057 tagged_above=-999 required=5 tests=[AWL=0.542, 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 zVGuupyNQZlv; Tue, 16 Aug 2011 10:39:04 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id E37B211E80F4; Tue, 16 Aug 2011 10:39:03 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQ100IIC7QED0@szxga05-in.huawei.com>; Wed, 17 Aug 2011 01:39:50 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQ1007OJ7QDQ3@szxga05-in.huawei.com>; Wed, 17 Aug 2011 01:39:50 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml206-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADF73727; Wed, 17 Aug 2011 01:39:49 +0800 (CST) Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 17 Aug 2011 01:39:45 +0800 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.177]) by szxeml410-hub.china.huawei.com ([169.254.101.122]) with mapi id 14.01.0270.001; Wed, 17 Aug 2011 01:39:45 +0800 Date: Tue, 16 Aug 2011 17:39:43 +0000 From: Tina TSOU X-Originating-IP: [10.193.34.126] To: "behave@ietf.org" , "pcp@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: two users request same address and port Thread-index: AcxcO3jp3sKqYmkyRu68rHYQ8viICg== X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AgvH BDbq Bhf1 CWDb C0C4 GIGK JVyz KMSl ML+p N6C2 OHYA PUn9 TQTS VFtu W66y Ya2O; 2; YgBlAGgAYQB2AGUAQABpAGUAdABmAC4AbwByAGcAOwBwAGMAcABAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {9CEFBBB8-2477-4FDF-B722-860D48EB766C}; dABpAG4AYQAuAHQAcwBvAHUALgB6AG8AdQB0AGkAbgBnAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Tue, 16 Aug 2011 17:39:39 GMT; dAB3AG8AIAB1AHMAZQByAHMAIAByAGUAcQB1AGUAcwB0ACAAcwBhAG0AZQAgAGEAZABkAHIAZQBzAHMAIABhAG4AZAAgAHAAbwByAHQA x-cr-puzzleid: {9CEFBBB8-2477-4FDF-B722-860D48EB766C} X-CFilter-Loop: Reflected X-Mailman-Approved-At: Wed, 17 Aug 2011 10:27:18 -0700 Subject: [BEHAVE] two users request same address and port 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, 16 Aug 2011 17:39:04 -0000 Hi guys, http://portforward.com/cports.htm If two end users using XBox request same IPv4 public external address on CGN, and same port, what will happen? The CGN still works with these applications listed above in the website link. Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html From wwwrun@rfc-editor.org Wed Aug 17 12:41: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 9926E1F0C39 for ; Wed, 17 Aug 2011 12:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.503 X-Spam-Level: X-Spam-Status: No, score=-102.503 tagged_above=-999 required=5 tests=[AWL=0.097, 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 IeXjFqO0zrYg for ; Wed, 17 Aug 2011 12:41:33 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id C85D61F0C35 for ; Wed, 17 Aug 2011 12:41:32 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 7A46498C228; Wed, 17 Aug 2011 12:42:23 -0700 (PDT) To: derek.macdonald@gmail.com, bbl@lowekamp.net, ietfdbh@comcast.net, wes@mti-systems.com, dthaler@microsoft.com, dwing@cisco.com From: RFC Errata System Message-Id: <20110817194223.7A46498C228@rfc-editor.org> Date: Wed, 17 Aug 2011 12:42:23 -0700 (PDT) Cc: jselbie@gmail.com, behave@ietf.org, rfc-editor@rfc-editor.org Subject: [BEHAVE] [Technical Errata Reported] RFC5780 (2939) 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, 17 Aug 2011 19:41:33 -0000 The following errata report has been submitted for RFC5780, "NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5780&eid=2939 -------------------------------------- Type: Technical Reported by: John Selbie Section: 9.1 Original Text ------------- Section 9.1 ... 0x802c: OTHER-ADDRESS Corrected Text -------------- Notes ----- Section 7.4 of RFC 5780 states: "OTHER-ADDRESS uses the same attribute number as CHANGED-ADDRESS from RFC 3489". (Defined as 0x0005 in rfc 3489). But section 9.1 of RFC 5780 defines the value of OTHER-ADDRESS as being 0x802c. Suggestion: Either update section 7.4 to not reference RFC 3489 or update the STUN attribute registry such that OTHER-ADDRESS remains at 0x0005. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5780 (draft-ietf-behave-nat-behavior-discovery-08) -------------------------------------- Title : NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN) Publication Date : May 2010 Author(s) : D. MacDonald, B. Lowekamp Category : EXPERIMENTAL Source : Behavior Engineering for Hindrance Avoidance Area : Transport Stream : IETF Verifying Party : IESG From dwing@cisco.com Wed Aug 17 15:25:31 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD8311E8090 for ; Wed, 17 Aug 2011 15:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qd1UxJNrZbCs for ; Wed, 17 Aug 2011 15:25:30 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4D17411E8081 for ; Wed, 17 Aug 2011 15:25:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2618; q=dns/txt; s=iport; t=1313619982; x=1314829582; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=4kHXSq8UZ4HxHLHAcUC99K9HzioRafEr1uCJZ+O4a0s=; b=AvQW7+8ud2mfdBLu+QmAtSgE2IhsizAJGjH640Z5Fz3iL6LV8P6Z9KCN kw/B3eAeGPdbgtmK0IFB9+dTleiubqHpVW/O8x/lAUWQv9UkcoSHxMxsL V0dbHouK1xBjJq/BmRtRYiYIJXVCui1sXYBiL2XQPUcfv6fv07VFKn+YE w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtcAALE+TE5Io8US/2dsb2JhbAAoGpkagWyNbHeBQAEBAQEDCAoBFxA/DAEDAgkPAgQBASgHGQgbCgkIAQEEARILF4dSI5dUAZ8IhkgEh2CVKYcfSQ X-IronPort-AV: E=Sophos;i="4.68,241,1312156800"; d="scan'208";a="111315001" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-1.cisco.com with ESMTP; 17 Aug 2011 22:26:20 +0000 Received: from dwingWS (sjc-vpn5-1625.cisco.com [10.21.94.89]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p7HMQGRm026258; Wed, 17 Aug 2011 22:26:17 GMT From: "Dan Wing" To: , References: <20110817194223.7A46498C228@rfc-editor.org> In-Reply-To: <20110817194223.7A46498C228@rfc-editor.org> Date: Wed, 17 Aug 2011 15:26:15 -0700 Message-ID: <1d8f01cc5d2c$af820620$0e861260$@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: AcxdFcnnc3i24u17QTW6AH5g/BqfdQAFppZQ Content-Language: en-us Cc: jselbie@gmail.com, behave@ietf.org, dthaler@microsoft.com Subject: Re: [BEHAVE] [Technical Errata Reported] RFC5780 (2939) 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, 17 Aug 2011 22:25:31 -0000 There _could_ be some case where RFC5780 needs to use OTHER-ADDRESS for OTHER-ADDRESS's intended purpose. We have a lot of space for STUN Attributes, so safest thing, I think, is declaring the text that says "OTHER-ADDRESS uses the same attribute number as CHANGED-ADDRESS from RFC 3489". as the error. Thoughts? -d > -----Original Message----- > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > Sent: Wednesday, August 17, 2011 12:42 PM > To: derek.macdonald@gmail.com; bbl@lowekamp.net; ietfdbh@comcast.net; > wes@mti-systems.com; dthaler@microsoft.com; dwing@cisco.com > Cc: jselbie@gmail.com; behave@ietf.org; rfc-editor@rfc-editor.org > Subject: [Technical Errata Reported] RFC5780 (2939) > > > The following errata report has been submitted for RFC5780, > "NAT Behavior Discovery Using Session Traversal Utilities for NAT > (STUN)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=5780&eid=2939 > > -------------------------------------- > Type: Technical > Reported by: John Selbie > > Section: 9.1 > > Original Text > ------------- > Section 9.1 > > ... > > 0x802c: OTHER-ADDRESS > > > > Corrected Text > -------------- > > > Notes > ----- > Section 7.4 of RFC 5780 states: "OTHER-ADDRESS uses the same attribute > number as CHANGED-ADDRESS from RFC 3489". (Defined as 0x0005 in rfc > 3489). > > > > But section 9.1 of RFC 5780 defines the value of OTHER-ADDRESS as being > 0x802c. > > > > Suggestion: Either update section 7.4 to not reference RFC 3489 or > update the STUN attribute registry such that OTHER-ADDRESS remains at > 0x0005. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC5780 (draft-ietf-behave-nat-behavior-discovery-08) > -------------------------------------- > Title : NAT Behavior Discovery Using Session Traversal > Utilities for NAT (STUN) > Publication Date : May 2010 > Author(s) : D. MacDonald, B. Lowekamp > Category : EXPERIMENTAL > Source : Behavior Engineering for Hindrance Avoidance > Area : Transport > Stream : IETF > Verifying Party : IESG From bruce@lowekamp.net Wed Aug 17 21:32: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 4AFB321F859F for ; Wed, 17 Aug 2011 21:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.277 X-Spam-Level: X-Spam-Status: No, score=-2.277 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 AEIHCsnSKivM for ; Wed, 17 Aug 2011 21:32:07 -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 615DB21F8563 for ; Wed, 17 Aug 2011 21:32:04 -0700 (PDT) Received: by gxk19 with SMTP id 19so1360802gxk.31 for ; Wed, 17 Aug 2011 21:32:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.147.16.28 with SMTP id t28mr256979yai.37.1313641975758; Wed, 17 Aug 2011 21:32:55 -0700 (PDT) Sender: bruce@lowekamp.net Received: by 10.147.137.4 with HTTP; Wed, 17 Aug 2011 21:32:55 -0700 (PDT) In-Reply-To: <20110817194223.7A46498C228@rfc-editor.org> References: <20110817194223.7A46498C228@rfc-editor.org> Date: Thu, 18 Aug 2011 00:32:55 -0400 X-Google-Sender-Auth: AvyUw89doQOF2TP4Ptzg7pZ4Bz0 Message-ID: From: Bruce Lowekamp To: RFC Errata System Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: behave@ietf.org, wes@mti-systems.com, dthaler@microsoft.com, jselbie@gmail.com, dwing@cisco.com, derek.macdonald@gmail.com, ietfdbh@comcast.net Subject: Re: [BEHAVE] [Technical Errata Reported] RFC5780 (2939) 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, 18 Aug 2011 04:38:39 -0000 Wow, this one really surprises me. We made that change in the -02 draft and somehow missed that paragraph the entire time after. Looking back on my slides from the change, I believe the paragraph in 7.4: OTHER-ADDRESS uses the same attribute number as CHANGED-ADDRESS from RFC 3489 [RFC3489] because it is simply a new name with the same semantics as CHANGED-ADDRESS. It has been renamed to more clearly indicate its function. should be deleted in its entirety. It was deliberately renumbered to break compatibility with 3489 clients. Bruce On Wed, Aug 17, 2011 at 3:42 PM, RFC Errata System wrote: > > The following errata report has been submitted for RFC5780, > "NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN)"= . > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D5780&eid=3D2939 > > -------------------------------------- > Type: Technical > Reported by: John Selbie > > Section: 9.1 > > Original Text > ------------- > Section 9.1 > =A0 ... > =A0 0x802c: OTHER-ADDRESS > > > Corrected Text > -------------- > > > Notes > ----- > Section 7.4 of RFC 5780 states: "OTHER-ADDRESS uses the same attribute nu= mber as CHANGED-ADDRESS from RFC 3489". (Defined as 0x0005 in rfc 3489). > > But section 9.1 of RFC 5780 defines the value of OTHER-ADDRESS as being 0= x802c. > > Suggestion: Either update section 7.4 to not reference RFC 3489 or update= the STUN attribute registry such that OTHER-ADDRESS remains at 0x0005. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC5780 (draft-ietf-behave-nat-behavior-discovery-08) > -------------------------------------- > Title =A0 =A0 =A0 =A0 =A0 =A0 =A0 : NAT Behavior Discovery Using Session = Traversal Utilities for NAT (STUN) > Publication Date =A0 =A0: May 2010 > Author(s) =A0 =A0 =A0 =A0 =A0 : D. MacDonald, B. Lowekamp > Category =A0 =A0 =A0 =A0 =A0 =A0: EXPERIMENTAL > Source =A0 =A0 =A0 =A0 =A0 =A0 =A0: Behavior Engineering for Hindrance Av= oidance > Area =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: Transport > Stream =A0 =A0 =A0 =A0 =A0 =A0 =A0: IETF > Verifying Party =A0 =A0 : IESG > From internet-drafts@ietf.org Thu Aug 18 07:04: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 2A05021F8B5C; Thu, 18 Aug 2011 07:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 jRQazOf6IW26; Thu, 18 Aug 2011 07:04:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C244121F8B2A; Thu, 18 Aug 2011 07:04:55 -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.58 Message-ID: <20110818140455.7844.45866.idtracker@ietfa.amsl.com> Date: Thu, 18 Aug 2011 07:04:55 -0700 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action: draft-ietf-behave-lsn-requirements-03.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 14:04: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 : 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-03.txt Pages : 18 Date : 2011-08-18 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-03.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-03.txt From simon.perreault@viagenie.ca Thu Aug 18 07:08:06 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C20621F8AE4 for ; Thu, 18 Aug 2011 07:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.244 X-Spam-Level: X-Spam-Status: No, score=-2.244 tagged_above=-999 required=5 tests=[AWL=-0.244, 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 iFJx38KA1KBl for ; Thu, 18 Aug 2011 07:08:05 -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 70C9621F8A36 for ; Thu, 18 Aug 2011 07:08:05 -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 3A8C221F49 for ; Thu, 18 Aug 2011 10:08:59 -0400 (EDT) Message-ID: <4E4D1CFA.5010301@viagenie.ca> Date: Thu, 18 Aug 2011 10:08:58 -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: <20110818140455.7844.45866.idtracker@ietfa.amsl.com> In-Reply-To: <20110818140455.7844.45866.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-03.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 14:08:06 -0000 This revision incorporates the changes discussed during the Quebec meeting as well as shortly afterwards on the mailing list. Here's the change log: o Added exceptions for which it is not necessary to wait 120 seconds before reusing a port. o Renamed "random port set" to "scattered port set", which is more accurate. o Log "subscriber identifier" instead of internal address+port to allow for overlapping internal address ranges (DS-Lite). o Adjusted logging text and added reference to I-D.boucadair-pppext- portrange-option. o Adjusted destination logging text for bulk port allocation schemes. o Removed requirement for I-D.ietf-intarea-ipv4-id-update. o Made PCP support a SHOULD-level requirement. o Lowered the level of requirement for not dropping existing mappings in order to "make room" to SHOULD level, and added rationale. We think this is now ready for WGLC. Simon On 2011-08-18 10:04, 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-03.txt > Pages : 18 > Date : 2011-08-18 > > 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-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-lsn-requirements-03.txt > _______________________________________________ > 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 dwing@cisco.com Thu Aug 18 17:22:19 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB0A21F8551 for ; Thu, 18 Aug 2011 17:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.417 X-Spam-Level: X-Spam-Status: No, score=-103.417 tagged_above=-999 required=5 tests=[AWL=-0.818, 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 5h-U+czCHuRw for ; Thu, 18 Aug 2011 17:22:18 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id DF91021F854D for ; Thu, 18 Aug 2011 17:22:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=178; q=dns/txt; s=iport; t=1313713392; x=1314922992; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=JQcIxpPhHr4a1EKgSoCjdcoxfAjJtbfaXfkJMJXb6Zw=; b=mVGX/DPShuf6GxWMwIbHUqucFgcpQQ0rfCvyP8gcO1oYsgDFh6oiRaEY 5T333/RNiLsC58vpzMNByy+B4tPBeIXx0xrj6KhJCt+ONZ/WkJEtX+IZL q/rcN8ablV6RebtuNSCZahOoyQTQ1m6l+1Z/IqnSqjGPzm6zXy9zZiJ2M 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigIAFysTU6rRDoI/2dsb2JhbABBmGiBKI1od4FHCAoBFxA/DQUYUCMVBwEEHAIXh1OYPgGefYZIBIdgnEg X-IronPort-AV: E=Sophos;i="4.68,248,1312156800"; d="scan'208";a="14517453" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-1.cisco.com with ESMTP; 19 Aug 2011 00:22:57 +0000 Received: from dwingWS (sjc-vpn2-679.cisco.com [10.21.114.167]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p7J0MuUr027643; Fri, 19 Aug 2011 00:22:56 GMT From: "Dan Wing" To: Date: Thu, 18 Aug 2011 17:22:56 -0700 Message-ID: <021e01cc5e06$24cfe1c0$6e6fa540$@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: AcxeBiSIZ4Yc9OPXTFe4Zb3ocavb9Q== Content-Language: en-us Cc: 'Behave Chairs' Subject: [BEHAVE] minutes posted 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, 19 Aug 2011 00:22:19 -0000 Minutes are now posted at http://www.ietf.org/proceedings/81/minutes/behave.txt inside there is a link to the mp3 recording. Let us know if you have corrections. -d From mohamed.boucadair@orange-ftgroup.com Fri Aug 19 06:57: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 148C021F86CA for ; Fri, 19 Aug 2011 06:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_74=0.6, 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 JrAw3LpdUtEy for ; Fri, 19 Aug 2011 06:57:43 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 07C3021F8634 for ; Fri, 19 Aug 2011 06:57:42 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 712FE3B46F1; Fri, 19 Aug 2011 15:58:38 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 59DD018006A; Fri, 19 Aug 2011 15:58:38 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Fri, 19 Aug 2011 15:58:38 +0200 From: To: Simon Perreault , "behave@ietf.org" Date: Fri, 19 Aug 2011 15:58:37 +0200 Thread-Topic: [BEHAVE] I-D Action: draft-ietf-behave-lsn-requirements-03.txt Thread-Index: AcxdsGN2c0nmAlE8QMeJu3grHGEQewAmSyhw Message-ID: <94C682931C08B048B7A8645303FDC9F33E54A63319@PUEXCB1B.nanterre.francetelecom.fr> References: <20110818140455.7844.45866.idtracker@ietfa.amsl.com> <4E4D1CFA.5010301@viagenie.ca> In-Reply-To: <4E4D1CFA.5010301@viagenie.ca> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" 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.8.19.123314 Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-lsn-requirements-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, 19 Aug 2011 13:57:44 -0000 Dear Simon, This version is much better than the -01; I didn't had a chance to read -02= . Some quick comments: * Port randomization should be supported by default. The current text only = discusses it for the port set case. * Some discussion on the external IP address pool is imho needed; in partic= ular to mention the external IP address pool is not necessary contiguous. B= TW, external address pool should be defined. * Add a reference to RFC4963 (e.g., in the security considerations section) Thanks, Cheers Med=20 -----Message d'origine----- De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de= Simon Perreault Envoy=E9 : jeudi 18 ao=FBt 2011 16:09 =C0 : behave@ietf.org Objet : Re: [BEHAVE] I-D Action: draft-ietf-behave-lsn-requirements-03.txt This revision incorporates the changes discussed during the Quebec meeting as well as shortly afterwards on the mailing list. Here's the change log: o Added exceptions for which it is not necessary to wait 120 seconds before reusing a port. o Renamed "random port set" to "scattered port set", which is more accurate. o Log "subscriber identifier" instead of internal address+port to allow for overlapping internal address ranges (DS-Lite). o Adjusted logging text and added reference to I-D.boucadair-pppext- portrange-option. o Adjusted destination logging text for bulk port allocation schemes. o Removed requirement for I-D.ietf-intarea-ipv4-id-update. o Made PCP support a SHOULD-level requirement. o Lowered the level of requirement for not dropping existing mappings in order to "make room" to SHOULD level, and added rationale. We think this is now ready for WGLC. Simon On 2011-08-18 10:04, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. This draft is a work item of the Behavior Engineering for Hindrance = Avoidance Working Group of the IETF. >=20 > Title : Common requirements for Carrier Grade NAT (CGN) > Author(s) : Simon Perreault > Ikuhei Yamagata > Shin Miyakawa > Akira Nakagawa > Hiroyuki Ashida > Filename : draft-ietf-behave-lsn-requirements-03.txt > Pages : 18 > Date : 2011-08-18 >=20 > This document defines common requirements for Carrier-Grade NAT > (CGN). >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-behave-lsn-requirements-03= .txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-lsn-requirements-03.= txt > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave --=20 DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From simon.perreault@viagenie.ca Fri Aug 19 07:20:11 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3F7E21F8A96 for ; Fri, 19 Aug 2011 07:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.062, 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 FEViHqHtQxJb for ; Fri, 19 Aug 2011 07:20:10 -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 4CEAE21F86BC for ; Fri, 19 Aug 2011 07:20:10 -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 E34242151D; Fri, 19 Aug 2011 10:21:06 -0400 (EDT) Message-ID: <4E4E7152.1030604@viagenie.ca> Date: Fri, 19 Aug 2011 10:21:06 -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: mohamed.boucadair@orange-ftgroup.com References: <20110818140455.7844.45866.idtracker@ietfa.amsl.com> <4E4D1CFA.5010301@viagenie.ca> <94C682931C08B048B7A8645303FDC9F33E54A63319@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F33E54A63319@PUEXCB1B.nanterre.francetelecom.fr> 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] I-D Action: draft-ietf-behave-lsn-requirements-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, 19 Aug 2011 14:20:11 -0000 On 2011-08-19 09:58, mohamed.boucadair@orange-ftgroup.com wrote: > * Port randomization should be supported by default. The current text > only discusses it for the port set case. I agree, but this is not specific to CGNs. Any NAT should do proper port randomization. What's different with CGNs is that you have multiple subscribers competing for the same resources, and so you have to ensure fairness. The security aspect of port randomization is the same. So I suggest that we add this to draft-penno-behave-rfc4787-5382-5508-bis instead. Some further notes on this: port randomization on a NAT isn't as easy (to specify) as on a host. There are a number of features that a NAT may or should implement. See RFC 4787 sections 4.2. So we'll have to think about it some more. > * Some discussion on the external IP address pool is imho needed; in > particular to mention the external IP address pool is not necessary > contiguous. BTW, external address pool should be defined. Can you please suggest some text? I'm not sure what needs to be said. > * Add a reference to RFC4963 (e.g., in the security considerations > section) Will do. 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 mohamed.boucadair@orange-ftgroup.com Mon Aug 22 01:54: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 9B12F21F8AFD for ; Mon, 22 Aug 2011 01:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=-0.258, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 Ly95uRp7fla3 for ; Mon, 22 Aug 2011 01:54:30 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id CE07F21F8AF8 for ; Mon, 22 Aug 2011 01:54:29 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id DDFCDC0114; Mon, 22 Aug 2011 10:55:32 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id C0BD9384075; Mon, 22 Aug 2011 10:55:32 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Mon, 22 Aug 2011 10:55:32 +0200 From: To: Simon Perreault Date: Mon, 22 Aug 2011 10:55:31 +0200 Thread-Topic: [BEHAVE] I-D Action: draft-ietf-behave-lsn-requirements-03.txt Thread-Index: Acxeez2Hpgn5yO9kS+yoQiyE43tjuQCLVvlg Message-ID: <94C682931C08B048B7A8645303FDC9F350C9DC4715@PUEXCB1B.nanterre.francetelecom.fr> References: <20110818140455.7844.45866.idtracker@ietfa.amsl.com> <4E4D1CFA.5010301@viagenie.ca> <94C682931C08B048B7A8645303FDC9F33E54A63319@PUEXCB1B.nanterre.francetelecom.fr> <4E4E7152.1030604@viagenie.ca> In-Reply-To: <4E4E7152.1030604@viagenie.ca> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" 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.8.21.30314 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-lsn-requirements-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: Mon, 22 Aug 2011 08:54:30 -0000 Dear Simon, Please see inline. Cheers, Med=20 -----Message d'origine----- De : Simon Perreault [mailto:simon.perreault@viagenie.ca]=20 Envoy=E9 : vendredi 19 ao=FBt 2011 16:21 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : behave@ietf.org Objet : Re: [BEHAVE] I-D Action: draft-ietf-behave-lsn-requirements-03.txt On 2011-08-19 09:58, mohamed.boucadair@orange-ftgroup.com wrote: > * Port randomization should be supported by default. The current text > only discusses it for the port set case. I agree, but this is not specific to CGNs. Any NAT should do proper port randomization. What's different with CGNs is that you have multiple subscribers competing for the same resources, and so you have to ensure fairness. The security aspect of port randomization is the same. So I suggest that we add this to draft-penno-behave-rfc4787-5382-5508-bis instead. Med: This makes sense but do you suggest to add a ref to draft-penno-behave= -rfc4787-5382-5508-bis? Some further notes on this: port randomization on a NAT isn't as easy (to specify) as on a host. There are a number of features that a NAT may or should implement. See RFC 4787 sections 4.2. So we'll have to think about it some more. > * Some discussion on the external IP address pool is imho needed; in > particular to mention the external IP address pool is not necessary > contiguous. BTW, external address pool should be defined. Can you please suggest some text? I'm not sure what needs to be said. Med: Below a text proposal: The CGN function is required to be configured with a set of IPv4 addresses, denoted as external IPv4 address pool. The CGN function SHOULD NOT have any pre-requisite on the size neither the contiguity of the external IP address pool. In particular, the CGN function SHOULD be able to be configured with contiguous and non-contiguous exter= nal IPv4 addresses. The pool of external IP addresses MUST be routable. > * Add a reference to RFC4963 (e.g., in the security considerations > section) Will do. Med: Thanks. From mohamed.boucadair@orange-ftgroup.com Mon Aug 22 02:00: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 EDEDC21F852C for ; Mon, 22 Aug 2011 02:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=-0.221, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 S9gUJ4sWWue9 for ; Mon, 22 Aug 2011 02:00:25 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id E3FC921F84ED for ; Mon, 22 Aug 2011 02:00:24 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id EFA58C01CB; Mon, 22 Aug 2011 11:01:28 +0200 (CEST) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id D916B180051; Mon, 22 Aug 2011 11:01:28 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Mon, 22 Aug 2011 11:01:28 +0200 From: To: Simon Perreault Date: Mon, 22 Aug 2011 11:01:28 +0200 Thread-Topic: [BEHAVE] I-D Action: draft-ietf-behave-lsn-requirements-03.txt Thread-Index: Acxeez2Hpgn5yO9kS+yoQiyE43tjuQCLVvlgAAA90GA= Message-ID: <94C682931C08B048B7A8645303FDC9F350C9DC4720@PUEXCB1B.nanterre.francetelecom.fr> References: <20110818140455.7844.45866.idtracker@ietfa.amsl.com> <4E4D1CFA.5010301@viagenie.ca> <94C682931C08B048B7A8645303FDC9F33E54A63319@PUEXCB1B.nanterre.francetelecom.fr> <4E4E7152.1030604@viagenie.ca> <94C682931C08B048B7A8645303FDC9F350C9DC4715@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F350C9DC4715@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="iso-8859-1" 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.8.22.31514 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-lsn-requirements-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: Mon, 22 Aug 2011 09:00:26 -0000 Re-=20 Please see inline. Cheers, Med -----Message d'origine----- De : Simon Perreault [mailto:simon.perreault@viagenie.ca]=20 Envoy=E9 : vendredi 19 ao=FBt 2011 16:21 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : behave@ietf.org Objet : Re: [BEHAVE] I-D Action: draft-ietf-behave-lsn-requirements-03.txt On 2011-08-19 09:58, mohamed.boucadair@orange-ftgroup.com wrote: > * Port randomization should be supported by default. The current text > only discusses it for the port set case. I agree, but this is not specific to CGNs. Any NAT should do proper port randomization. What's different with CGNs is that you have multiple subscribers competing for the same resources, and so you have to ensure fairness. The security aspect of port randomization is the same. So I suggest that we add this to draft-penno-behave-rfc4787-5382-5508-bis instead. Med: This makes sense but do you suggest to add a ref to draft-penno-behave= -rfc4787-5382-5508-bis? Med2: Instead of adding a pointer to draft-penno-*, the following text: "This document builds upon previous works describing requirements for generic NATs [RFC4787][RFC5382][RFC5508]. These documents still apply in this context. What follows are additional requirements, to be satisfied on top of previous ones." can be updated to something like the following: " This document builds upon previous works describing requirements for generic NATs [RFC4787][RFC5382][RFC5508]. These documents, and their up= dates if any, still apply in this context. What follows are additional requirements, to be satisfied on top of previous ones."= From simon.perreault@viagenie.ca Mon Aug 22 03:40: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 23C5821F8538 for ; Mon, 22 Aug 2011 03:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 FHkoB7hsh3P6 for ; Mon, 22 Aug 2011 03:40:34 -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 9036321F8507 for ; Mon, 22 Aug 2011 03:40:34 -0700 (PDT) Received: from banana.viagenie.ca (unknown [75.98.19.132]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 2A2A620D2A; Mon, 22 Aug 2011 06:41:37 -0400 (EDT) Message-ID: <4E523260.6020805@viagenie.ca> Date: Mon, 22 Aug 2011 06:41:36 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20110707 Thunderbird/5.0 MIME-Version: 1.0 To: mohamed.boucadair@orange-ftgroup.com References: <20110818140455.7844.45866.idtracker@ietfa.amsl.com> <4E4D1CFA.5010301@viagenie.ca> <94C682931C08B048B7A8645303FDC9F33E54A63319@PUEXCB1B.nanterre.francetelecom.fr> <4E4E7152.1030604@viagenie.ca> <94C682931C08B048B7A8645303FDC9F350C9DC4715@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F350C9DC4715@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-lsn-requirements-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: Mon, 22 Aug 2011 10:40:42 -0000 mohamed.boucadair@orange-ftgroup.com wrote, on 08/22/2011 04:55 AM: > Dear Simon, > > Please see inline. > > Cheers, > Med > > -----Message d'origine----- > De : Simon Perreault [mailto:simon.perreault@viagenie.ca] > Envoyé : vendredi 19 août 2011 16:21 > À : BOUCADAIR Mohamed OLNC/NAD/TIP > Cc : behave@ietf.org > Objet : Re: [BEHAVE] I-D Action: draft-ietf-behave-lsn-requirements-03.txt > > On 2011-08-19 09:58, mohamed.boucadair@orange-ftgroup.com wrote: >> * Port randomization should be supported by default. The current text >> only discusses it for the port set case. > > I agree, but this is not specific to CGNs. Any NAT should do proper port > randomization. What's different with CGNs is that you have multiple > subscribers competing for the same resources, and so you have to ensure > fairness. The security aspect of port randomization is the same. > > So I suggest that we add this to > draft-penno-behave-rfc4787-5382-5508-bis instead. > > Med: This makes sense but do you suggest to add a ref to draft-penno-behave-rfc4787-5382-5508-bis? No. The suggestion in your other mail makes perfect sense to me. >> * Some discussion on the external IP address pool is imho needed; in >> particular to mention the external IP address pool is not necessary >> contiguous. BTW, external address pool should be defined. > > Can you please suggest some text? I'm not sure what needs to be said. > > Med: Below a text proposal: > > The CGN function is required to be configured with a set of IPv4 > addresses, denoted as external IPv4 address pool. The CGN function > SHOULD NOT have any pre-requisite on the size neither the contiguity > of the external IP address pool. In particular, the CGN function > SHOULD be able to be configured with contiguous and non-contiguous external IPv4 > addresses. The pool of external IP addresses MUST be routable. Thanks. Unless the working group disagrees, this will be in the next revision. (But I will wait after WGLC to produce this new revision.) 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 simon.perreault@viagenie.ca Mon Aug 22 03:41: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 AA0BC21F8B1A for ; Mon, 22 Aug 2011 03:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 HZOtGUF13L-z for ; Mon, 22 Aug 2011 03:41:27 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 390D921F8B19 for ; Mon, 22 Aug 2011 03:41:27 -0700 (PDT) Received: from banana.viagenie.ca (unknown [75.98.19.132]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 5BF8A20D2A; Mon, 22 Aug 2011 06:42:31 -0400 (EDT) Message-ID: <4E523296.9090900@viagenie.ca> Date: Mon, 22 Aug 2011 06:42:30 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20110707 Thunderbird/5.0 MIME-Version: 1.0 To: mohamed.boucadair@orange-ftgroup.com References: <20110818140455.7844.45866.idtracker@ietfa.amsl.com> <4E4D1CFA.5010301@viagenie.ca> <94C682931C08B048B7A8645303FDC9F33E54A63319@PUEXCB1B.nanterre.francetelecom.fr> <4E4E7152.1030604@viagenie.ca> <94C682931C08B048B7A8645303FDC9F350C9DC4715@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F350C9DC4720@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F350C9DC4720@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-lsn-requirements-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: Mon, 22 Aug 2011 10:41:27 -0000 mohamed.boucadair@orange-ftgroup.com wrote, on 08/22/2011 05:01 AM: > Med2: Instead of adding a pointer to draft-penno-*, the following text: > > "This document builds upon previous works describing requirements for > generic NATs [RFC4787][RFC5382][RFC5508]. These documents still > apply in this context. What follows are additional requirements, to > be satisfied on top of previous ones." > > can be updated to something like the following: > > " This document builds upon previous works describing requirements for > generic NATs [RFC4787][RFC5382][RFC5508]. These documents, and their updates if any, still > apply in this context. What follows are additional requirements, to > be satisfied on top of previous ones." Makes perfect sense. 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 jselbie@gmail.com Tue Aug 23 11:15: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 C0A9F21F8BE5 for ; Tue, 23 Aug 2011 11:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6QfpPw0at8u for ; Tue, 23 Aug 2011 11:15:00 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id B4F1021F8AFE for ; Tue, 23 Aug 2011 11:15:00 -0700 (PDT) Received: by yie12 with SMTP id 12so354047yie.31 for ; Tue, 23 Aug 2011 11:16:09 -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; bh=mkJb5wC6qMtI/SLl9qAEztcvLXfQHIKZ8+/tRNUmcPw=; b=TfD7GJYPNldN+4TThFSJZsQc8VgheiBtXmoqb7zz/JXCGK1ABR/S66mNDkk68jxnqT PS52Q0a+Kp7wZlvNMgmyyWpbY1EnXKuXBoyeYqzjvIidI63YI2oQUdWx3h6qgadFk0YR 3gj+kkAnXfLZup4Et7JFU214x8Q0HEe0Zu70w= MIME-Version: 1.0 Received: by 10.142.149.25 with SMTP id w25mr2233624wfd.308.1314123368522; Tue, 23 Aug 2011 11:16:08 -0700 (PDT) Received: by 10.142.177.12 with HTTP; Tue, 23 Aug 2011 11:16:08 -0700 (PDT) In-Reply-To: References: <20110817194223.7A46498C228@rfc-editor.org> Date: Tue, 23 Aug 2011 11:16:08 -0700 Message-ID: From: John Selbie To: Bruce Lowekamp Content-Type: multipart/alternative; boundary=000e0cd28d9892657104ab303015 X-Mailman-Approved-At: Wed, 24 Aug 2011 10:18:56 -0700 Cc: behave@ietf.org, wes@mti-systems.com, dthaler@microsoft.com, dwing@cisco.com, derek.macdonald@gmail.com, ietfdbh@comcast.net, RFC Errata System Subject: Re: [BEHAVE] [Technical Errata Reported] RFC5780 (2939) 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, 23 Aug 2011 19:11:01 -0000 --000e0cd28d9892657104ab303015 Content-Type: text/plain; charset=ISO-8859-1 Could a STUN server could be selective about using either based on the client request type? If the client request is missing the stun magic cookie, then it could be assumed to be written to rfc 3489. As such the server sends back the legacy CHANGED-ADDRESS attribute. Otherwise send back OTHER-ADDRESS if the client request contains the stun magic cookie. Or just send both? Would that be permissible? Can you elaborate on why it was "deliberately renumbered to break compatibility with 3489" ? As I read the behavior for handling "change-request" and calculating the "other address" as described in both 3489 (section 8.1) and 5780 (section 6.1) the text appear to be near identical in description. That is, the stun response always contains an attribute containing the other IP and other port opposite from which the request arrived on? Yes? Or is there some subtle difference I'm missing? Is there an email exchange discussion for STUN, TURN, and NAT traversal? jrs On Wed, Aug 17, 2011 at 9:32 PM, Bruce Lowekamp wrote: > Wow, this one really surprises me. We made that change in the -02 > draft and somehow missed that paragraph the entire time after. > > Looking back on my slides from the change, I believe the paragraph in 7.4: > > OTHER-ADDRESS uses the same attribute number as CHANGED-ADDRESS from > RFC 3489 [RFC3489] because it is simply a new name with the same > semantics as CHANGED-ADDRESS. It has been renamed to more clearly > indicate its function. > > should be deleted in its entirety. It was deliberately renumbered to > break compatibility with 3489 clients. > > Bruce > > On Wed, Aug 17, 2011 at 3:42 PM, RFC Errata System > wrote: > > > > The following errata report has been submitted for RFC5780, > > "NAT Behavior Discovery Using Session Traversal Utilities for NAT > (STUN)". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=5780&eid=2939 > > > > -------------------------------------- > > Type: Technical > > Reported by: John Selbie > > > > Section: 9.1 > > > > Original Text > > ------------- > > Section 9.1 > > ... > > 0x802c: OTHER-ADDRESS > > > > > > Corrected Text > > -------------- > > > > > > Notes > > ----- > > Section 7.4 of RFC 5780 states: "OTHER-ADDRESS uses the same attribute > number as CHANGED-ADDRESS from RFC 3489". (Defined as 0x0005 in rfc 3489). > > > > But section 9.1 of RFC 5780 defines the value of OTHER-ADDRESS as being > 0x802c. > > > > Suggestion: Either update section 7.4 to not reference RFC 3489 or update > the STUN attribute registry such that OTHER-ADDRESS remains at 0x0005. > > > > Instructions: > > ------------- > > This errata is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party (IESG) > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC5780 (draft-ietf-behave-nat-behavior-discovery-08) > > -------------------------------------- > > Title : NAT Behavior Discovery Using Session Traversal > Utilities for NAT (STUN) > > Publication Date : May 2010 > > Author(s) : D. MacDonald, B. Lowekamp > > Category : EXPERIMENTAL > > Source : Behavior Engineering for Hindrance Avoidance > > Area : Transport > > Stream : IETF > > Verifying Party : IESG > > > --000e0cd28d9892657104ab303015 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Could a STUN server could be selective about using either based on the clie= nt request type?=A0 If the client request is missing the stun magic cookie,= then it could be assumed to be written to rfc 3489.=A0 As such the server = sends back the legacy CHANGED-ADDRESS attribute. Otherwise send back OTHER-= ADDRESS if the client request contains the stun magic cookie.=A0 Or just se= nd both?=A0 Would that be permissible?

Can you elaborate on why it was "deliberately renumbered to break = compatibility with 3489" ?=A0 As I read the behavior for handling &quo= t;change-request" and calculating the "other address" as des= cribed in both 3489 (section 8.1) and 5780 (section 6.1) the text appear to= be near identical in description.=A0 That is, the stun response always con= tains an attribute containing the other IP and other port opposite from whi= ch the request arrived on?=A0 Yes?=A0 Or is there some subtle difference I&= #39;m missing?

Is there an email exchange discussion for STUN, TURN, and NAT traversal= ?

jrs


On Wed, Aug 17, 2011 at = 9:32 PM, Bruce Lowekamp <bbl@lowekamp.net> wrote:
Wow, this one really surprises me. =A0We ma= de that change in the -02
draft and somehow missed that paragraph the entire time after.

Looking back on my slides from the change, I believe the paragraph in 7.4:<= br>

=A0 OTHER-ADDRESS uses the same attribute number as CHANGED-ADDRESS from
=A0 RFC 3489 [RFC3489] because it is simply a new name with the same=
=A0 semantics as CHANGED-ADDRESS. =A0It has been renamed to more clearly =A0 indicate its function.

should be deleted in its entirety. =A0It was deliberately renumbered to
break compatibility with 3489 clients.

Bruce

On Wed, Aug 17, 2011 at 3:42 PM, RFC Errata System
<rfc-editor@rfc-editor.org<= /a>> wrote:
>
> The following errata report has been submitted for RFC5780,
> "NAT Behavior Discovery Using Session Traversal Utilities for NAT= (STUN)".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?r= fc=3D5780&eid=3D2939
>
> --------------------------------------
> Type: Technical
> Reported by: John Selbie <jsel= bie@gmail.com>
>
> Section: 9.1
>
> Original Text
> -------------
> Section 9.1
> =A0 ...
> =A0 0x802c: OTHER-ADDRESS
>
>
> Corrected Text
> --------------
>
>
> Notes
> -----
> Section 7.4 of RFC 5780 states: "OTHER-ADDRESS uses the same attr= ibute number as CHANGED-ADDRESS from RFC 3489". (Defined as 0x0005 in = rfc 3489).
>
> But section 9.1 of RFC 5780 defines the value of OTHER-ADDRESS as bein= g 0x802c.
>
> Suggestion: Either update section 7.4 to not reference RFC 3489 or upd= ate the STUN attribute registry such that OTHER-ADDRESS remains at 0x0005.<= br> >
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary,= please
> use "Reply All" to discuss whether it should be verified or<= br> > rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC5780 (draft-ietf-behave-nat-behavior-discovery-08)
> --------------------------------------
> Title =A0 =A0 =A0 =A0 =A0 =A0 =A0 : NAT Behavior Discovery Using Sessi= on Traversal Utilities for NAT (STUN)
> Publication Date =A0 =A0: May 2010
> Author(s) =A0 =A0 =A0 =A0 =A0 : D. MacDonald, B. Lowekamp
> Category =A0 =A0 =A0 =A0 =A0 =A0: EXPERIMENTAL
> Source =A0 =A0 =A0 =A0 =A0 =A0 =A0: Behavior Engineering for Hindrance= Avoidance
> Area =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: Transport
> Stream =A0 =A0 =A0 =A0 =A0 =A0 =A0: IETF
> Verifying Party =A0 =A0 : IESG
>

--000e0cd28d9892657104ab303015-- From simon.perreault@viagenie.ca Wed Aug 24 10:36: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 4AD0121F8B72 for ; Wed, 24 Aug 2011 10:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.030, 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 HNskoIAOHlA9 for ; Wed, 24 Aug 2011 10:36: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 A72CF21F8B2A for ; Wed, 24 Aug 2011 10:36: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 2E8B820DC4; Wed, 24 Aug 2011 13:37:44 -0400 (EDT) Message-ID: <4E5536E7.30305@viagenie.ca> Date: Wed, 24 Aug 2011 13:37:43 -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: John Selbie References: <20110817194223.7A46498C228@rfc-editor.org> 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, wes@mti-systems.com, dthaler@microsoft.com, dwing@cisco.com, derek.macdonald@gmail.com, ietfdbh@comcast.net, RFC Errata System Subject: Re: [BEHAVE] [Technical Errata Reported] RFC5780 (2939) 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, 24 Aug 2011 17:36:39 -0000 On 2011-08-23 14:16, John Selbie wrote: > Could a STUN server could be selective about using either based on the > client request type? If the client request is missing the stun magic > cookie, then it could be assumed to be written to rfc 3489. As such the > server sends back the legacy CHANGED-ADDRESS attribute. Otherwise send > back OTHER-ADDRESS if the client request contains the stun magic > cookie. Or just send both? Would that be permissible? I sure hope so. We use that method in Numb (URL in sig) to decide whether we should reply to a Binding request with a MAPPED-ADDRESS or a XOR-MAPPED-ADDRESS parameter. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From rpenno@juniper.net Thu Aug 25 13:51: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 A5F1521F8C59 for ; Thu, 25 Aug 2011 13:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.457 X-Spam-Level: X-Spam-Status: No, score=-6.457 tagged_above=-999 required=5 tests=[AWL=0.142, 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 J7WYlGC0Tnog for ; Thu, 25 Aug 2011 13:51:13 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id BEA4C21F8C3C for ; Thu, 25 Aug 2011 13:51:12 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKTla2CladAIdC/TprRPpSnvAI+pGQV8Ns@postini.com; Thu, 25 Aug 2011 13:52:27 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 25 Aug 2011 13:51:53 -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; Thu, 25 Aug 2011 16:51:52 -0400 From: Reinaldo Penno To: "behave@ietf.org" Date: Thu, 25 Aug 2011 16:51:51 -0400 Thread-Topic: [BEHAVE] I-D Action: draft-ietf-behave-lsn-requirements-03.txt Thread-Index: AcxdsATC0gpVMrsVTOKhyT8tsBwhewFuMuVx Message-ID: In-Reply-To: <20110818140455.7844.45866.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.9.0.110114 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-lsn-requirements-03.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 20:51:13 -0000 Hello,=20 Some comments on this draft. 1 - " REQ-3: A CGN SHOULD limit the number of external ports (or, equivalently, "identifiers" for ICMP) that are assigned per subscriber. --- snip ---- C. Additionally, it is RECOMMENDED that the CGN include administrator-adjustable thresholds to prevent a single subscriber from consuming excessive CPU resources from the CGN (e.g. rate limit the subscriber's creation of new mappings). " I do not agree that CPU consumption is related to number of external ports. As the last sentence clarifies, the number of sessions per second is what i= s important and not absolute number. Therefore I suggest changing the wording on REQ-3 to read ...limit the number or rate of... 2 -=20 REQ-4: A CGN SHOULD limit the amount of state memory allocated per mapping and per subscriber. This may include limiting the number of TCP sessions, the number of filters, etc., depending on the NAT implementation. This seems a superset of REQ-3 But more to the point, I'm not sure this belongs in the draft because there are cases it is not needed: - Some other device in the network performs this function - without any NAT associated with it - No SLA exists or should be expected by subscribers. Therefore this function is not needed. 3 - REQ-6: It is RECOMMENDED that a CGN have an "Endpoint-Independent Filtering" behavior. Justification: This is a stronger form of REQ-8 from [RFC4787]. An "Address-Dependent Filtering" behavior is NOT RECOMMENDED. This is based on the observation that some games and peer-to-peer applications require EIF for the NAT traversal to work. In the context of a CGN it is important to minimise application breakage. I suggest we reword to say that EIF is recommend for those applications and not a blanket statement saying it is always recommended. Otherwise there is no problem with Address-Dependent Filtering. The security considerations discussed in 4787 are important. EIF opens a security hole and therefore that text needed to be copied here or reference= d since there are CGN deployments where security is the more important consideration. 4 -=20 REQ-12: When a CGN is unable to create a mapping due to resource constraints or administrative restrictions (i.e. quotas)... .. D. and it SHOULD NOT delete existing mappings in order to "make room" for the new one. Unless the quota per subscriber was, say, 400, but the configuration change= d to 200. But a user has 300 ports. Those extra 100 ports can be reclaimed to make room. Or not? Thanks, Reinaldo On 8/18/11 7:04 AM, "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. >=20 > Title : Common requirements for Carrier Grade NAT (CGN) > Author(s) : Simon Perreault > Ikuhei Yamagata > Shin Miyakawa > Akira Nakagawa > Hiroyuki Ashida > Filename : draft-ietf-behave-lsn-requirements-03.txt > Pages : 18 > Date : 2011-08-18 >=20 > This document defines common requirements for Carrier-Grade NAT > (CGN). >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-behave-lsn-requirements-03= .txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-lsn-requirements-03.= txt > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From roberta.maglione@telecomitalia.it Fri Aug 26 05:55: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 444F921F84EB for ; Fri, 26 Aug 2011 05:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.202 X-Spam-Level: * X-Spam-Status: No, score=1.202 tagged_above=-999 required=5 tests=[AWL=-0.493, BAYES_40=-0.185, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 FiRq75HPP0iE for ; Fri, 26 Aug 2011 05:55:39 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id 7546021F84E9 for ; Fri, 26 Aug 2011 05:55:39 -0700 (PDT) Received: from GRFHUB702BA020.griffon.local (10.188.101.112) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 26 Aug 2011 14:56:50 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by GRFHUB702BA020.griffon.local ([10.188.101.112]) with mapi; Fri, 26 Aug 2011 14:56:50 +0200 From: Maglione Roberta To: "'behave@ietf.org'" Date: Fri, 26 Aug 2011 14:56:50 +0200 Thread-Topic: Question on draft-ietf-behave-lsn-requirements-03.txt Thread-Index: Acxj7567MSyHFhmhToaipwwx7VuprA== Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53DAC@GRFMBX704BA020.griffon.local> Accept-Language: en-US, it-IT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [BEHAVE] Question on draft-ietf-behave-lsn-requirements-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, 26 Aug 2011 12:55:40 -0000 Hello, I have a question about section 5. Bulk Port Allocation: I understand this section discusses about the impacts of allocating multipl= e ports, but why there is no requirement in the document talking about Bulk= Port Allocation? In my opinion it would be useful to add in section 3 at least a simple requ= irement about Bulk Port Allocation, for example something like: REQ-XX: The CGN MUST support Bulk Port Allocation. The port set allocated b= y the CGN can be Consecutive or Scattered. Comments? Thanks, Best regards, Roberta Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From mohamed.boucadair@orange-ftgroup.com Fri Aug 26 06:19:43 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B69A121F8B5F for ; Fri, 26 Aug 2011 06:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.389 X-Spam-Level: X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 rshcF4Xad45u for ; Fri, 26 Aug 2011 06:19:43 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id F0E3521F8B37 for ; Fri, 26 Aug 2011 06:19:42 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 0F7A9C0389; Fri, 26 Aug 2011 15:20:56 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id EDCFD384064; Fri, 26 Aug 2011 15:20:55 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Fri, 26 Aug 2011 15:20:55 +0200 From: To: Maglione Roberta , "'behave@ietf.org'" Date: Fri, 26 Aug 2011 15:20:54 +0200 Thread-Topic: Question on draft-ietf-behave-lsn-requirements-03.txt Thread-Index: Acxj7567MSyHFhmhToaipwwx7VuprAAAybUA Message-ID: <94C682931C08B048B7A8645303FDC9F35166FB87D8@PUEXCB1B.nanterre.francetelecom.fr> References: <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53DAC@GRFMBX704BA020.griffon.local> In-Reply-To: <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53DAC@GRFMBX704BA020.griffon.local> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" 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.8.26.112414 Subject: Re: [BEHAVE] Question on draft-ietf-behave-lsn-requirements-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, 26 Aug 2011 13:19:43 -0000 Hi Reberta, FYI, this point was discussed in this thread: http://www.ietf.org/mail-arch= ive/web/behave/current/msg09300.html. I still support the idea of having an explicit requirement to support the p= ort set mode. Cheers, Med =20 -----Message d'origine----- De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de= Maglione Roberta Envoy=E9 : vendredi 26 ao=FBt 2011 14:57 =C0 : 'behave@ietf.org' Objet : [BEHAVE] Question on draft-ietf-behave-lsn-requirements-03.txt Hello, I have a question about section 5. Bulk Port Allocation: I understand this section discusses about the impacts of allocating multipl= e ports, but why there is no requirement in the document talking about Bulk= Port Allocation? In my opinion it would be useful to add in section 3 at least a simple requ= irement about Bulk Port Allocation, for example something like: REQ-XX: The CGN MUST support Bulk Port Allocation. The port set allocated b= y the CGN can be Consecutive or Scattered. Comments? Thanks, Best regards, Roberta Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From swmike@swm.pp.se Fri Aug 26 23:30:29 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6435F21F8AAC for ; Fri, 26 Aug 2011 23:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 5-sc9CwlYJIH for ; Fri, 26 Aug 2011 23:30:29 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id CB9BB21F8AAA for ; Fri, 26 Aug 2011 23:30:27 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 6B6A69C; Sat, 27 Aug 2011 08:31:42 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 66C479A; Sat, 27 Aug 2011 08:31:42 +0200 (CEST) Date: Sat, 27 Aug 2011 08:31:42 +0200 (CEST) From: Mikael Abrahamsson To: Maglione Roberta In-Reply-To: <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53DAC@GRFMBX704BA020.griffon.local> Message-ID: References: <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53DAC@GRFMBX704BA020.griffon.local> 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] Question on draft-ietf-behave-lsn-requirements-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: Sat, 27 Aug 2011 06:30:29 -0000 On Fri, 26 Aug 2011, Maglione Roberta wrote: > Hello, > I have a question about section 5. Bulk Port Allocation: > > I understand this section discusses about the impacts of allocating multiple ports, but why there is no requirement in the document talking about Bulk Port Allocation? > > In my opinion it would be useful to add in section 3 at least a simple requirement about Bulk Port Allocation, for example something like: > > REQ-XX: The CGN MUST support Bulk Port Allocation. The port set allocated by the CGN can be Consecutive or Scattered. > > Comments? I support making it a MUST requirement, due to the fact that without it, it's nearly impossible to handle the logging load. I also feel that support for both consecutive and scattered must be supported. -- Mikael Abrahamsson email: swmike@swm.pp.se From bbl@lowekamp.net Sat Aug 27 14: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 6B59C21F8B38 for ; Sat, 27 Aug 2011 14:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.363 X-Spam-Level: X-Spam-Status: No, score=-2.363 tagged_above=-999 required=5 tests=[AWL=0.614, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 nftwCfMrSTRD for ; Sat, 27 Aug 2011 14:13:44 -0700 (PDT) Received: from mail-ey0-f174.google.com (mail-ey0-f174.google.com [209.85.215.174]) by ietfa.amsl.com (Postfix) with ESMTP id 562F021F8B35 for ; Sat, 27 Aug 2011 14:13:44 -0700 (PDT) Received: by eyx24 with SMTP id 24so3435917eyx.19 for ; Sat, 27 Aug 2011 14:15:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.11.8 with SMTP id 8mr993448eew.82.1314479702622; Sat, 27 Aug 2011 14:15:02 -0700 (PDT) Received: by 10.14.127.72 with HTTP; Sat, 27 Aug 2011 14:15:02 -0700 (PDT) In-Reply-To: References: <20110817194223.7A46498C228@rfc-editor.org> Date: Sat, 27 Aug 2011 17:15:02 -0400 Message-ID: From: Bruce Lowekamp To: John Selbie Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: behave@ietf.org, wes@mti-systems.com, dthaler@microsoft.com, dwing@cisco.com, derek.macdonald@gmail.com, ietfdbh@comcast.net, RFC Errata System Subject: Re: [BEHAVE] [Technical Errata Reported] RFC5780 (2939) 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, 27 Aug 2011 21:13:45 -0000 On Tue, Aug 23, 2011 at 2:16 PM, John Selbie wrote: > Could a STUN server could be selective about using either based on the > client request type?=C2=A0 If the client request is missing the stun magi= c > cookie, then it could be assumed to be written to rfc 3489.=C2=A0 As such= the > server sends back the legacy CHANGED-ADDRESS attribute. Otherwise send ba= ck > OTHER-ADDRESS if the client request contains the stun magic cookie.=C2=A0= Or just > send both?=C2=A0 Would that be permissible? Yes, one intention was that if you wanted to, you could distinguish between the two protocols using the magic cookie. > Can you elaborate on why it was "deliberately renumbered to break > compatibility with 3489" ?=C2=A0 As I read the behavior for handling > "change-request" and calculating the "other address" as described in both > 3489 (section 8.1) and 5780 (section 6.1) the text appear to be near > identical in description.=C2=A0 That is, the stun response always contain= s an > attribute containing the other IP and other port opposite from which the > request arrived on?=C2=A0 Yes?=C2=A0 Or is there some subtle difference I= 'm missing? The desire to break compatibility had more to do with the intended (and described) uses of 3489 than with this actual aspect of the protocol. The intention was to ensure that applications written with 3489's characterization approach hard-coded be updated to reflect how to use ICE, etc for NAT traversal, even if they applied some of the same techniques that are now in 5780 for appropriate reasons. > Is there an email exchange discussion for STUN, TURN, and NAT traversal? STUN and TURN came from behave, so I guess it's still good to discuss them = here. Bruce > > jrs > > > On Wed, Aug 17, 2011 at 9:32 PM, Bruce Lowekamp wrote: >> >> Wow, this one really surprises me. =C2=A0We made that change in the -02 >> draft and somehow missed that paragraph the entire time after. >> >> Looking back on my slides from the change, I believe the paragraph in 7.= 4: >> >> =C2=A0 OTHER-ADDRESS uses the same attribute number as CHANGED-ADDRESS f= rom >> =C2=A0 RFC 3489 [RFC3489] because it is simply a new name with the same >> =C2=A0 semantics as CHANGED-ADDRESS. =C2=A0It has been renamed to more c= learly >> =C2=A0 indicate its function. >> >> should be deleted in its entirety. =C2=A0It was deliberately renumbered = to >> break compatibility with 3489 clients. >> >> Bruce >> >> On Wed, Aug 17, 2011 at 3:42 PM, RFC Errata System >> wrote: >> > >> > The following errata report has been submitted for RFC5780, >> > "NAT Behavior Discovery Using Session Traversal Utilities for NAT >> > (STUN)". >> > >> > -------------------------------------- >> > You may review the report below and at: >> > http://www.rfc-editor.org/errata_search.php?rfc=3D5780&eid=3D2939 >> > >> > -------------------------------------- >> > Type: Technical >> > Reported by: John Selbie >> > >> > Section: 9.1 >> > >> > Original Text >> > ------------- >> > Section 9.1 >> > =C2=A0 ... >> > =C2=A0 0x802c: OTHER-ADDRESS >> > >> > >> > Corrected Text >> > -------------- >> > >> > >> > Notes >> > ----- >> > Section 7.4 of RFC 5780 states: "OTHER-ADDRESS uses the same attribute >> > number as CHANGED-ADDRESS from RFC 3489". (Defined as 0x0005 in rfc 34= 89). >> > >> > But section 9.1 of RFC 5780 defines the value of OTHER-ADDRESS as bein= g >> > 0x802c. >> > >> > Suggestion: Either update section 7.4 to not reference RFC 3489 or >> > update the STUN attribute registry such that OTHER-ADDRESS remains at >> > 0x0005. >> > >> > Instructions: >> > ------------- >> > This errata is currently posted as "Reported". If necessary, please >> > use "Reply All" to discuss whether it should be verified or >> > rejected. When a decision is reached, the verifying party (IESG) >> > can log in to change the status and edit the report, if necessary. >> > >> > -------------------------------------- >> > RFC5780 (draft-ietf-behave-nat-behavior-discovery-08) >> > -------------------------------------- >> > Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : NAT Behavior = Discovery Using Session Traversal >> > Utilities for NAT (STUN) >> > Publication Date =C2=A0 =C2=A0: May 2010 >> > Author(s) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : D. MacDonald, B. Loweka= mp >> > Category =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: EXPERIMENTAL >> > Source =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Behavior Engi= neering for Hindrance Avoidance >> > Area =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Transpor= t >> > Stream =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: IETF >> > Verifying Party =C2=A0 =C2=A0 : IESG >> > > > From iesg-secretary@ietf.org Wed Aug 31 06:53: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 AB2DB21F8B7E; Wed, 31 Aug 2011 06:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a6vNlwXSx7hc; Wed, 31 Aug 2011 06:53:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37D7421F8B52; Wed, 31 Aug 2011 06:53:49 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110831135349.14909.10061.idtracker@ietfa.amsl.com> Date: Wed, 31 Aug 2011 06:53:49 -0700 Cc: behave@ietf.org Subject: [BEHAVE] Last Call: (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 13:53:49 -0000 The IESG has received a request from the Behavior Engineering for Hindrance Avoidance WG (behave) to consider the following document: - 'Dual Stack Hosts Using "Bump-in-the-Host" (BIH)' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-09-14. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Bump-In-the-Host (BIH) is a host-based IPv4 to IPv6 protocol translation mechanism that allows a class of IPv4-only applications that work through NATs to communicate with IPv6-only peers. The host on which applications are running may be connected to IPv6-only or dual-stack access networks. BIH hides IPv6 and makes the IPv4-only applications think they are talking with IPv4 peers by local synthesis of IPv4 addresses. This draft obsoletes RFC 2767 and RFC 3338. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-behave-v4v6-bih/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-behave-v4v6-bih/ No IPR declarations have been submitted directly on this I-D. From simon.perreault@viagenie.ca Wed Aug 31 07:15: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 3611C21F8BE7 for ; Wed, 31 Aug 2011 07:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 XlPrf8sfBgIY for ; Wed, 31 Aug 2011 07:15:14 -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 8FA2D21F8BBC for ; Wed, 31 Aug 2011 07:15:14 -0700 (PDT) Received: from banana.viagenie.ca (nomis80.org [97.107.136.111]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 60B0D21E3F for ; Wed, 31 Aug 2011 10:16:41 -0400 (EDT) Message-ID: <4E5E424A.1020003@viagenie.ca> Date: Wed, 31 Aug 2011 10:16:42 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20110707 Thunderbird/5.0 MIME-Version: 1.0 To: behave@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-lsn-requirements-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: Wed, 31 Aug 2011 14:15:37 -0000 Reinaldo Penno wrote, on 08/25/2011 04:51 PM: > 1 - > > " REQ-3: A CGN SHOULD limit the number of external ports (or, > equivalently, "identifiers" for ICMP) that are assigned per > subscriber. > > --- snip ---- > > C. Additionally, it is RECOMMENDED that the CGN include > administrator-adjustable thresholds to prevent a single > subscriber from consuming excessive CPU resources from > the CGN (e.g. rate limit the subscriber's creation of new > mappings). > " > > I do not agree that CPU consumption is related to number of external ports. > As the last sentence clarifies, the number of sessions per second is what is > important and not absolute number. Therefore I suggest changing the wording > on REQ-3 to read > > ...limit the number or rate of... I don't understand your point. - The finite resource being protected by REQ-3 is external ports. - The finite resource being protected by REQ-3-C is CPU cycles. REQ-3-C is worded very generally so that any CPU-consuming operation needs to be limited, and the rate of mapping creation is given as an example. So this all seems to agree with what you said. > 2 - > > REQ-4: A CGN SHOULD limit the amount of state memory allocated per > mapping and per subscriber. This may include limiting the > number of TCP sessions, the number of filters, etc., > depending on the NAT implementation. > > This seems a superset of REQ-3 - The finite resource being protected by REQ-3 is external ports. - The finite resource being protected by REQ-4 is memory. These are very different requirements. > But more to the point, I'm not sure this belongs in the draft because there > are cases it is not needed: > > - Some other device in the network performs this function - without any NAT > associated with it > > - No SLA exists or should be expected by subscribers. Therefore this > function is not needed. I don't understand. NATs create state, which uses memory, a finite resource. CGNs are NATs that are shared my multiple subscribers that might be competing for the same finite resource. Therefore this operator needs a way to ensure fairness. This principle, fairness, is the cornerstone of this document, and has been agreed upon by the WG from the start. It is in the interest of the Internet that subscribers are allowed a fair share of resources. > 3 - > > REQ-6: It is RECOMMENDED that a CGN have an "Endpoint-Independent > Filtering" behavior. > > Justification: This is a stronger form of REQ-8 from [RFC4787]. An > "Address-Dependent Filtering" behavior is NOT RECOMMENDED. This > is based on the observation that some games and peer-to-peer > applications require EIF for the NAT traversal to work. In the > context of a CGN it is important to minimise application breakage. > > I suggest we reword to say that EIF is recommend for those applications and > not a blanket statement saying it is always recommended. Otherwise there is > no problem with Address-Dependent Filtering. I agree that we need to add text to identify the exceptions to the recommendation. In light of the RFC2119 discussion on ietf@ietf.org, we need to adopt the SHOULD...UNLESS... pattern. How about something like: It is RECOMMENDED that a CGN have an "Endpoint-Independent Filtering" behavior UNLESS it is known that "Address-Dependent Filtering" does not cause the application layer protocol to break. And I would remove the "An "Address-Dependent Filtering" behavior is NOT RECOMMENDED." part because it is redundant. How about that? > The security considerations discussed in 4787 are important. EIF opens a > security hole and therefore that text needed to be copied here or referenced > since there are CGN deployments where security is the more important > consideration. Agreed, will do. > 4 - > > REQ-12: When a CGN is unable to create a mapping due to resource > constraints or administrative restrictions (i.e. quotas)... > .. > > D. and it SHOULD NOT delete existing mappings in order to > "make room" for the new one. > > > Unless the quota per subscriber was, say, 400, but the configuration changed > to 200. But a user has 300 ports. Those extra 100 ports can be reclaimed to > make room. Or not? I suppose they can. This requirement applies to implicitly-created mappings (e.g. with a TCP SYN), not to operator intervention. I'll make that clear in the next revision. 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 simon.perreault@viagenie.ca Wed Aug 31 07:25: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 EE6CD21F8BA0 for ; Wed, 31 Aug 2011 07:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 mtIbG8fn9VDA for ; Wed, 31 Aug 2011 07:25:46 -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 683F521F8B5A for ; Wed, 31 Aug 2011 07:25:46 -0700 (PDT) Received: from banana.viagenie.ca (nomis80.org [97.107.136.111]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 54A5821E3F for ; Wed, 31 Aug 2011 10:27:16 -0400 (EDT) Message-ID: <4E5E44C5.3030400@viagenie.ca> Date: Wed, 31 Aug 2011 10:27:17 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20110707 Thunderbird/5.0 MIME-Version: 1.0 To: behave@ietf.org References: <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53DAC@GRFMBX704BA020.griffon.local> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] Question on draft-ietf-behave-lsn-requirements-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: Wed, 31 Aug 2011 14:25:47 -0000 Mikael Abrahamsson wrote, on 08/27/2011 02:31 AM: > I support making it a MUST requirement, due to the fact that without it, it's > nearly impossible to handle the logging load. According to previous calculations, the logging load is not unmanageable. See . 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 simon.perreault@viagenie.ca Wed Aug 31 07:30:51 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B40221F8BA0 for ; Wed, 31 Aug 2011 07:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 mBTcK7Kincmu for ; Wed, 31 Aug 2011 07:30:50 -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 8C1D621F8B9C for ; Wed, 31 Aug 2011 07:30:50 -0700 (PDT) Received: from banana.viagenie.ca (nomis80.org [97.107.136.111]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 7CA3921E3F for ; Wed, 31 Aug 2011 10:32:20 -0400 (EDT) Message-ID: <4E5E45E6.7010106@viagenie.ca> Date: Wed, 31 Aug 2011 10:32:06 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20110707 Thunderbird/5.0 MIME-Version: 1.0 To: behave@ietf.org References: <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53DAC@GRFMBX704BA020.griffon.local> In-Reply-To: <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53DAC@GRFMBX704BA020.griffon.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] Question on draft-ietf-behave-lsn-requirements-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: Wed, 31 Aug 2011 14:30:51 -0000 Maglione Roberta wrote, on 08/26/2011 08:56 AM: > In my opinion it would be useful to add in section 3 at least a simple > requirement about Bulk Port Allocation, for example something like: > > REQ-XX: The CGN MUST support Bulk Port Allocation. The port set allocated by > the CGN can be Consecutive or Scattered. As the document editor, I need rationale text for this proposed requirement. I think the best way forward to suggest a new requirement would be to send proposed rationale text to the mailing list so as to reach a consensus that I can edit into the document. Otherwise I have nothing to work with, and I'll have to request WGLC from the chairs. 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 Jean-Francois.TremblayING@videotron.com Wed Aug 31 10:35: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 101DB21F8E20; Wed, 31 Aug 2011 10:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.300, 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 OleoLoMHbYsx; Wed, 31 Aug 2011 10:35:36 -0700 (PDT) Received: from mx02.videotron.com (mx02.videotron.com [24.201.243.151]) by ietfa.amsl.com (Postfix) with ESMTP id 781EB21F8E1A; Wed, 31 Aug 2011 10:35:36 -0700 (PDT) In-Reply-To: <4E5E44C5.3030400@viagenie.ca> To: simon.perreault@viagenie.ca MIME-Version: 1.0 X-KeepSent: E9A4BFDB:DE0152F0-852578FD:005FC51A; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 Message-ID: From: Jean-Francois.TremblayING@videotron.com Date: Wed, 31 Aug 2011 13:36:39 -0400 X-MIMETrack: Serialize by Router on DOMMSG01/SRV/GVL(Release 8.5.2FP2|March 22, 2011) at 08/31/2011 13:36:44, Serialize complete at 08/31/2011 13:36:44 Content-Type: multipart/alternative; boundary="=_alternative 0060BD76852578FD_=" Cc: behave-bounces@ietf.org, behave@ietf.org Subject: Re: [BEHAVE] Question on draft-ietf-behave-lsn-requirements-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: Wed, 31 Aug 2011 17:35:37 -0000 Message en plusieurs parties au format MIME --=_alternative 0060BD76852578FD_= Content-Type: text/plain; charset="US-ASCII" >Mikael Abrahamsson wrote, on 08/27/2011 02:31 AM: >> I support making it a MUST requirement, due to the fact that without it, it's >> nearly impossible to handle the logging load. > According to previous calculations, the logging load is not unmanageable. > See . > Simon +1 on the MUST here. >From an operator perspective, logging is barely manageable, if not unmanageable at all, without bulk/range/block allocation. It could be managed, but at a very high cost both for the logging systems and its operations. The rationale here is that in many countries, law enforcement agencies mandate to keep these logs for at least a year, sometimes even longer. With the numbers you refered to above (2.7 TB/day), this means nearly 1 Petabyte of storage per year *per CGN device*. And this is only storing, we haven't discussed the operational nightmare of filtering, searching and reporting on this data. /JF --=_alternative 0060BD76852578FD_= Content-Type: text/html; charset="US-ASCII"
>Mikael Abrahamsson wrote, on 08/27/2011 02:31 AM:
>> I support making it a MUST requirement, due to the fact that without it, it's
>> nearly impossible to handle the logging load.
> According to previous calculations, the logging load is not unmanageable.
> See <http://www.ietf.org/mail-archive/web/behave/current/msg08801.html>.
> Simon
+1 on the MUST here.

From an operator perspective, logging is barely manageable, if not unmanageable at all,
without bulk/range/block allocation. It could be managed, but at a very high cost both
for the logging systems and its operations.

The rationale here is that in many countries, law enforcement agencies mandate to keep
these logs for at least a year, sometimes even longer. With the numbers you refered
to above (2.7 TB/day), this means nearly 1 Petabyte of storage per year *per CGN device*.
And this is only storing, we haven't discussed the operational nightmare of filtering,
searching and reporting on this data.

/JF
--=_alternative 0060BD76852578FD_=-- From simon.perreault@viagenie.ca Wed Aug 31 10:58: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 C022D21F8E6D for ; Wed, 31 Aug 2011 10:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 3SaAr0rmW3U3 for ; Wed, 31 Aug 2011 10:58:39 -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 167C421F8E58 for ; Wed, 31 Aug 2011 10:58:39 -0700 (PDT) Received: from banana.viagenie.ca (nomis80.org [97.107.136.111]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 32EA621C75; Wed, 31 Aug 2011 14:00:09 -0400 (EDT) Message-ID: <4E5E76AA.3050208@viagenie.ca> Date: Wed, 31 Aug 2011 14:00:10 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20110707 Thunderbird/5.0 MIME-Version: 1.0 To: Jean-Francois.TremblayING@videotron.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: behave@ietf.org Subject: Re: [BEHAVE] Question on draft-ietf-behave-lsn-requirements-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: Wed, 31 Aug 2011 17:58:39 -0000 Jean-Francois.TremblayING@videotron.com wrote, on 08/31/2011 01:36 PM: > The rationale here is that in many countries, law enforcement agencies mandate > to keep > these logs for at least a year, sometimes even longer. Not disagreeing with you, but I fear that this rationale would go against RFC2804: The IETF has decided not to consider requirements for wiretapping as part of the process for creating and maintaining IETF standards. I feel like it would make a stronger rationale if we focus on other advantages of bulk port allocation... > With the numbers you refered > to above (2.7 TB/day), this means nearly 1 Petabyte of storage per year *per CGN > device*. That with 1,000,000 bindings/sec, which is a lot. That's 15 IP addresses worth of external ports consumed per second. That's a really big NAT! 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 Jean-Francois.TremblayING@videotron.com Wed Aug 31 11:40: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 4EFBE21F8E2F; Wed, 31 Aug 2011 11:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.373 X-Spam-Level: X-Spam-Status: No, score=-2.373 tagged_above=-999 required=5 tests=[AWL=0.225, 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 cJLHSgh8eSyZ; Wed, 31 Aug 2011 11:40:06 -0700 (PDT) Received: from mx02.videotron.com (mx02.videotron.com [24.201.243.151]) by ietfa.amsl.com (Postfix) with ESMTP id A731021F8DF6; Wed, 31 Aug 2011 11:40:06 -0700 (PDT) In-Reply-To: <4E5E76AA.3050208@viagenie.ca> To: simon.perreault@viagenie.ca MIME-Version: 1.0 X-KeepSent: F3D9D4A6:47F6DA4E-852578FD:0064492C; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 Message-ID: From: Jean-Francois.TremblayING@videotron.com Date: Wed, 31 Aug 2011 14:41:11 -0400 X-MIMETrack: Serialize by Router on DOMMSG01/SRV/GVL(Release 8.5.2FP2|March 22, 2011) at 08/31/2011 14:41:17, Serialize complete at 08/31/2011 14:41:17 Content-Type: multipart/alternative; boundary="=_alternative 0066A630852578FD_=" Cc: behave-bounces@ietf.org, behave@ietf.org Subject: Re: [BEHAVE] Question on draft-ietf-behave-lsn-requirements-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: Wed, 31 Aug 2011 18:40:07 -0000 Message en plusieurs parties au format MIME --=_alternative 0066A630852578FD_= Content-Type: text/plain; charset="US-ASCII" >> The rationale here is that in many countries, law enforcement agencies mandate >> to keep these logs for at least a year, sometimes even longer. > Not disagreeing with you, but I fear that this rationale would go against RFC2804: > > The IETF has decided not to consider requirements for wiretapping as > part of the process for creating and maintaining IETF standards. > > I feel like it would make a stronger rationale if we focus on other advantages > of bulk port allocation... Good point. The definition of wiretapping in RFC2804 is wide enough that logging source ports is probably (barely) included in this context. Other advantages would be interesting, but I can't see any other reason to keep logs on the long term besides heating a building with spinning hard drives. >> With the numbers you refered >> to above (2.7 TB/day), this means nearly 1 Petabyte of storage per year *per CGN >> device*. > That with 1,000,000 bindings/sec, which is a lot. That's 15 IP addresses worth > of external ports consumed per second. That's a really big NAT! Of course, but even if logging is an order of magnitude smaller, this is only one NAT box in a network presumably using several CGNs. CGN is, by definition, a really big NAT. Logging without port ranges remains a non-trivial an operational problem. /JF --=_alternative 0066A630852578FD_= Content-Type: text/html; charset="US-ASCII"
>> The rationale here is that in many countries, law enforcement agencies mandate
>> to keep these logs for at least a year, sometimes even longer.
> Not disagreeing with you, but I fear that this rationale would go against RFC2804:
>
>   The IETF has decided not to consider requirements for wiretapping as
>   part of the process for creating and maintaining IETF standards.
>
> I feel like it would make a stronger rationale if we focus on other advantages
> of bulk port allocation...
Good point. The definition of wiretapping in RFC2804 is wide enough that logging
source ports is probably (barely) included in this context.

Other advantages would be interesting, but I can't see any other reason to keep
logs on the long term besides heating a building with spinning hard drives.


>> With the numbers you refered
>> to above (2.7 TB/day), this means nearly 1 Petabyte of storage per year *per CGN
>> device*.
> That with 1,000,000 bindings/sec, which is a lot. That's 15 IP addresses worth
> of external ports consumed per second. That's a really big NAT!
Of course, but even if logging is an order of magnitude smaller, this is only one
NAT box in a network presumably using several CGNs. CGN is, by definition,
a really big NAT. Logging without port ranges remains a non-trivial an operational problem.

/JF

--=_alternative 0066A630852578FD_=-- From rpenno@juniper.net Wed Aug 31 13:40:06 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 273A621F8EFF for ; Wed, 31 Aug 2011 13:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.501 X-Spam-Level: X-Spam-Status: No, score=-6.501 tagged_above=-999 required=5 tests=[AWL=0.098, 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 EZhlq4mGGOMP for ; Wed, 31 Aug 2011 13:40:05 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id 465F021F8DDC for ; Wed, 31 Aug 2011 13:40:04 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKTl6cf7RdJIky4tmtE/qU1RYxutv8d/5e@postini.com; Wed, 31 Aug 2011 13:41:36 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 31 Aug 2011 11:22:23 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Wed, 31 Aug 2011 14:22:22 -0400 From: Reinaldo Penno To: Simon Perreault , "behave@ietf.org" Date: Wed, 31 Aug 2011 14:22:19 -0400 Thread-Topic: [BEHAVE] I-D Action: draft-ietf-behave-lsn-requirements-03.txt Thread-Index: Acxn6K6Cf0bAqhuZS5+RHAIeDDmhjwAIjyX5 Message-ID: In-Reply-To: <4E5E424A.1020003@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.9.0.110114 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-lsn-requirements-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: Wed, 31 Aug 2011 20:40:06 -0000 First of all let me clarify that I'm not against this requirement per se bu= t I think we should give room for the market to play out instead making 'policy' - as in 'market regulation'. IMO ports is just like bandwidth, a shared resource. Both are very important. There are ISPs that provide some minimum bandwidth guarantees on their network for each sub. Some say you will get 'up to X-Mbps', which theoretically could be zero. Therefore my suggestion is that "...a CGN box SHOULD _support_ the ability to provide a fair share of ports across subscriber..." but it is up to the ISP to turn it on and how much. Maybe there is an ISP that leverage the statistical multiplexing of ports coming and going and charges $5 per month. Another ISP guarantees at least 100 ports and charges $15. The subscriber is free to choose whatever it prefers. On 8/31/11 7:16 AM, "Simon Perreault" wrote: > 2 -=20 >=20 > REQ-4: A CGN SHOULD limit the amount of state memory allocated per > mapping and per subscriber. This may include limiting the > number of TCP sessions, the number of filters, etc., > depending on the NAT implementation. >=20 > This seems a superset of REQ-3 >> But more to the point, I'm not sure this belongs in the draft because th= ere >> are cases it is not needed: >>=20 >> - Some other device in the network performs this function - without any = NAT >> associated with it >>=20 >> - No SLA exists or should be expected by subscribers. Therefore this >> function is not needed. >=20 > I don't understand. NATs create state, which uses memory, a finite resour= ce. > CGNs are NATs that are shared my multiple subscribers that might be compe= ting > for the same finite resource. Therefore this operator needs a way to ensu= re > fairness. This principle, fairness, is the cornerstone of this document, = and > has > been agreed upon by the WG from the start. It is in the interest of the > Internet > that subscribers are allowed a fair share of resources. From swmike@swm.pp.se Wed Aug 31 22:05: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 2ED4021F8B33 for ; Wed, 31 Aug 2011 22:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.249, BAYES_00=-2.599, J_CHICKENPOX_42=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 GmXybRHf52UN for ; Wed, 31 Aug 2011 22:05:17 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id A73C521F8B05 for ; Wed, 31 Aug 2011 22:05:16 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 098459C; Thu, 1 Sep 2011 07:06:46 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 072799A; Thu, 1 Sep 2011 07:06:46 +0200 (CEST) Date: Thu, 1 Sep 2011 07:06:46 +0200 (CEST) From: Mikael Abrahamsson To: Simon Perreault In-Reply-To: <4E5E44C5.3030400@viagenie.ca> Message-ID: References: <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53DAC@GRFMBX704BA020.griffon.local> <4E5E44C5.3030400@viagenie.ca> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: behave@ietf.org Subject: Re: [BEHAVE] Question on draft-ietf-behave-lsn-requirements-03.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 05:05:18 -0000 On Wed, 31 Aug 2011, Simon Perreault wrote: > Mikael Abrahamsson wrote, on 08/27/2011 02:31 AM: >> I support making it a MUST requirement, due to the fact that without it, it's >> nearly impossible to handle the logging load. > > According to previous calculations, the logging load is not unmanageable. > See . There are markets where there is either already a requirement, or talk about putting into law a requirement to save such data for 3 years. When one is talking about many tens of gigabits/s of traffic we're talking really serious storage systems (hundreds of terabytes if not thousands of terabytes of storage). Avoiding logging any kind of destination information is to be preferred, only logging the source port range being made available for the customer and requiring the party wanting information to supply time,IP address and port to track an individual user, makes the logging load go down by factor 1000 or more in our calculations. -- Mikael Abrahamsson email: swmike@swm.pp.se From swmike@swm.pp.se Wed Aug 31 22:09: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 DDAF521F8A4D; Wed, 31 Aug 2011 22:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 6QcJKfsSsvZo; Wed, 31 Aug 2011 22:09:56 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 872DF21F8A23; Wed, 31 Aug 2011 22:09:55 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 1E0869C; Thu, 1 Sep 2011 07:11:24 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 1CA9D9A; Thu, 1 Sep 2011 07:11:24 +0200 (CEST) Date: Thu, 1 Sep 2011 07:11:24 +0200 (CEST) From: Mikael Abrahamsson To: Jean-Francois.TremblayING@videotron.com 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; charset=US-ASCII; format=flowed Cc: behave-bounces@ietf.org, behave@ietf.org Subject: Re: [BEHAVE] Question on draft-ietf-behave-lsn-requirements-03.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 05:09:57 -0000 On Wed, 31 Aug 2011, Jean-Francois.TremblayING@videotron.com wrote: > Other advantages would be interesting, but I can't see any other reason > to keep logs on the long term besides heating a building with spinning > hard drives. Well, I'd say being a good netizen and being able to do regular abuse tracking, means one often wants to save logs for months anyway. Creating a logging system to handle the rate of data being creating by flow export costs more to aquire than the CGN device itself when we looked into it. A lot of ISPs do not log this today so they can't really do abuse tracking at all. -- Mikael Abrahamsson email: swmike@swm.pp.se