From Tina.Tsou.Zouting@huawei.com Tue Jul 3 10:02:11 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F9D211E8098 for ; Tue, 3 Jul 2012 10:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.782 X-Spam-Level: X-Spam-Status: No, score=-5.782 tagged_above=-999 required=5 tests=[AWL=0.816, 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 S74gb1EO2Gh2 for ; Tue, 3 Jul 2012 10:02:10 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3E55811E8096 for ; Tue, 3 Jul 2012 10:02:10 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHK20684; Tue, 03 Jul 2012 13:02:18 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 3 Jul 2012 10:00:57 -0700 Received: from dfweml513-mbx.china.huawei.com ([169.254.3.208]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.003; Tue, 3 Jul 2012 10:00:56 -0700 From: Tina TSOU To: 'Behave WG' Thread-Topic: New Version Notification for draft-zhou-behave-syslog-nat-logging-00.txt Thread-Index: AQHNWOjUYf8qB0KdTk2PM0FAeNSNvJcXyP8o Date: Tue, 3 Jul 2012 17:00:55 +0000 Message-ID: <75D0C497-DF71-4124-B8D0-705614B15C24@huawei.com> References: <20120703065512.21662.72625.idtracker@ietfa.amsl.com> In-Reply-To: <20120703065512.21662.72625.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_75D0C497DF714124B8D0705614B15C24huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [BEHAVE] Fwd: New Version Notification for draft-zhou-behave-syslog-nat-logging-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 17:02:11 -0000 --_000_75D0C497DF714124B8D0705614B15C24huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable For your comments. Tina Begin forwarded message: From: > Date: July 2, 2012 11:55:12 PM PDT To: > Cc: >, <1= 8918588897@189.cn> Subject: New Version Notification for draft-zhou-behave-syslog-nat-logging-= 00.txt A new version of I-D, draft-zhou-behave-syslog-nat-logging-00.txt has been successfully submitted by Cathy Zhou and posted to the IETF repository. Filename: draft-zhou-behave-syslog-nat-logging Revision: 00 Title: The Syslog Requirements to Support NAT Log in Traceback Solu= tions Creation date: 2012-07-03 WG ID: Individual Submission Number of pages: 12 URL: http://www.ietf.org/internet-drafts/draft-zhou-behave-sysl= og-nat-logging-00.txt Status: http://datatracker.ietf.org/doc/draft-zhou-behave-syslog-n= at-logging Htmlized: http://tools.ietf.org/html/draft-zhou-behave-syslog-nat-lo= gging-00 Abstract: This document describes the syslog information that are required for NAT logging. The document will define the NAT logging server which supports traceback and explain the procedure of network location and service support for traceback. The requirements of syslog interface and Radius interface to support NAT log are introduced. The IETF Secretariat --_000_75D0C497DF714124B8D0705614B15C24huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
For your comments.

Tina

Begin forwarded message:

From: <internet-= drafts@ietf.org>
Date: July 2, 2012 11:55:12 PM PDT
To: <cathy.zhou@huawei.c= om>
Cc: <tina.tsou.zo= uting@huawei.com>, <1891858= 8897@189.cn>
Subject: New Version Notification for draft-zhou-behave-syslog-na= t-logging-00.txt


A new version of I-D, draft-zhou-behave-syslog-nat-logging-00.txt
has been successfully submitted by Cathy Zhou and posted to the
IETF repository.

Filename:     draft-zhou-behave-syslog-nat-logging Revision:     00
Title:         The Syslog Requirements to Support= NAT Log in Traceback Solutions
Creation date:     2012-07-03
WG ID:         Individual Submission
Number of pages: 12
URL:           &nbs= p; http://www.ietf.org/internet-drafts/draft-zhou-beh= ave-syslog-nat-logging-00.txt
Status:          h= ttp://datatracker.ietf.org/doc/draft-zhou-behave-syslog-nat-logging
Htmlized:        http://tools.= ietf.org/html/draft-zhou-behave-syslog-nat-logging-00


Abstract:
  This document describes the syslog information that are r= equired for
  NAT logging.  The document will define the NAT loggi= ng server which
  supports traceback and explain the procedure of network l= ocation and
  service support for traceback.  The requirements of = syslog interface
  and Radius interface to support NAT log are introduced.




The IETF Secretariat
--_000_75D0C497DF714124B8D0705614B15C24huaweicom_-- From wesley.george@twcable.com Fri Jul 6 09:51:06 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54F0E21F8600; Fri, 6 Jul 2012 09:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.195 X-Spam-Level: X-Spam-Status: No, score=-1.195 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 cZgoDYlnpJ5A; Fri, 6 Jul 2012 09:51:05 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id F29E721F85C7; Fri, 6 Jul 2012 09:51:04 -0700 (PDT) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.77,539,1336363200"; d="scan'208";a="406312740" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 06 Jul 2012 12:50:24 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Fri, 6 Jul 2012 12:50:37 -0400 From: "George, Wes" To: "ietf@ietf.org" Date: Fri, 6 Jul 2012 12:50:36 -0400 Thread-Topic: Last Call: (Common requirements for Carrier Grade NATs (CGNs)) to Best Current Practice Thread-Index: Ac1bl3YdX1C7JyBWSKeRw6dAKK2Mcg== Message-ID: 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-Mailman-Approved-At: Sat, 07 Jul 2012 09:02:29 -0700 Cc: "behave@ietf.org" , "sunset4@ietf.org" Subject: Re: [BEHAVE] Last Call: (Common requirements for Carrier Grade NATs (CGNs)) to Best Current Practice X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 16:51:06 -0000 I have a comment about this document related to some discussions that I've = had with a number of ADs and WG chairs around the formation and charter of = Sunset4 to determine what is and is not in scope for that WG. For a while both BEHAVE and Sunset4 had this document in their milestones, = which clearly won't work. Therefore the distinction made between work to be= done in BEHAVE and SUNSET4 was that BEHAVE was to focus more generically o= n the concept of NAT and the things necessary to make all flavors of it wor= k, such that BEHAVE outputs would equally apply to NAT444, NAT64, DSLite, e= tc. By contrast, Sunset4 was supposed to focus more narrowly on IPv4-only i= tems. The BEHAVE chairs were represented in these discussions, and they bel= ieved that this document was in keeping with this distinction. In the document's introduction, for example, that generic nature is implied= : "It is not an IETF endorsement of CGN or a real specification for CGN, but rather just a minimal set of requirements that will increase the likelihood of applications working across CGNs." However, this document states in section 2: "Note also that the CGN described in this document is IPv4-only. IPv6 address translation is not considered." I see that this is a new change to the -07 version, so I hate to rehash the= discussion, but I think that this statement should be clearer. In reading the document, I don't believe that the intent was to limit it to= being a discussion of NAT44[4], but that could be the way that this statem= ent is interpreted. The distinction I might make to clarify is that since t= he document is talking about behaviors that are necessary to make IPv4 addr= ess-sharing work, it's specific to the IPv4 side of what could well be a du= al-stack NAT, but it's not limited to simply NAT44[4]. I'm not advocating pulling this document back so that it can go to the "rig= ht" working group, because I don't think that'll actually add any value to = the document and I'm not a fan of process for process's sake. My concern is= really more about content and naming- if it is truly a IPv4-only NAT (NAT4= 4 or NAT444) requirements doc rather than a more generic CGN requirements d= oc, it should be named to reflect that. If it's meant to be a generic LSN r= equirements doc, the authors should make the appropriate changes to keep it= generic. Thanks, Wes George, at least partially wearing my Sunset4 chair hat > -----Original Message----- > From: ietf-announce-bounces@ietf.org [mailto:ietf-announce- > bounces@ietf.org] On Behalf Of The IESG > Sent: Tuesday, June 26, 2012 12:59 PM > To: IETF-Announce > Cc: behave@ietf.org > Subject: Last Call: (Common > requirements for Carrier Grade NATs (CGNs)) to Best Current Practice > > > The IESG has received a request from the Behavior Engineering for > Hindrance Avoidance WG (behave) to consider the following document: > - 'Common requirements for Carrier Grade NATs (CGNs)' > as Best Current Practice > > 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 2012-07-10. 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 > > > This document defines common requirements for Carrier-Grade NAT > (CGN). It updates RFC 4787. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-behave-lsn-requirements/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-behave-lsn- > requirements/ballot/ > > > The following IPR Declarations may be related to this I-D: > > http://datatracker.ietf.org/ipr/1648/ > > This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From simon.perreault@viagenie.ca Sat Jul 7 14:21:55 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FEDF21F8638; Sat, 7 Jul 2012 14:21:55 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOO9ZnkE+zXf; Sat, 7 Jul 2012 14:21:53 -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 C4BAF21F861C; Sat, 7 Jul 2012 14:21:52 -0700 (PDT) Received: from eeepc.viagenie.ca (211.17-ppp.3menatwork.com [72.0.211.17]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 6D8C041631; Sat, 7 Jul 2012 17:22:11 -0400 (EDT) Message-ID: <4FF8A836.2090407@viagenie.ca> Date: Sat, 07 Jul 2012 14:20:54 -0700 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; OpenBSD i386; rv:9.0) Gecko/20120207 Thunderbird/9.0.1 MIME-Version: 1.0 To: "George, Wes" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "behave@ietf.org" , "ietf@ietf.org" , "sunset4@ietf.org" Subject: Re: [BEHAVE] Last Call: (Common requirements for Carrier Grade NATs (CGNs)) to Best Current Practice X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jul 2012 21:21:55 -0000 Wes, Here's my take on this... CGN as defined in this document does not only include NAT444. It is more generic than that: it really means "multi-user NAT". Dave Thaler came up with the example use case of the NAT in a wifi hotspot. It's just NAT44, but it still fits with the draft's definition of CGN because you have multiple users potentially fighting for the same NAT resources. Remember that the main raison d'être of this draft is for the operator to be able to ensure fairness between NAT users. So in this view I think it is clearly behave material since the sunsetting of IPv4 really is orthogonal to multi-user NATs. On the question of IPv6: I don't think we should talk about IPv6 simply because IPv6 NAT so far has not seen significant deployment in the context of multi-user NAT. And NPTv6 is stateless so there are no resources to fight for. Back to your email, where you wrote: > if it is truly a IPv4-only NAT (NAT44 or NAT444) requirements doc rather than a more generic CGN requirements doc, it should be named to reflect that. How about "Common Requirements for IPv4 Carrier Grade NATs (CGNs)"? Thanks, Simon On 07/06/12 09:50, George, Wes wrote: > I have a comment about this document related to some discussions that I've had with a number of ADs and WG chairs around the formation and charter of Sunset4 to determine what is and is not in scope for that WG. > > For a while both BEHAVE and Sunset4 had this document in their milestones, which clearly won't work. Therefore the distinction made between work to be done in BEHAVE and SUNSET4 was that BEHAVE was to focus more generically on the concept of NAT and the things necessary to make all flavors of it work, such that BEHAVE outputs would equally apply to NAT444, NAT64, DSLite, etc. By contrast, Sunset4 was supposed to focus more narrowly on IPv4-only items. The BEHAVE chairs were represented in these discussions, and they believed that this document was in keeping with this distinction. > In the document's introduction, for example, that generic nature is implied: > "It is not an IETF endorsement > of CGN or a real specification for CGN, but rather just a minimal set > of requirements that will increase the likelihood of applications > working across CGNs." > > However, this document states in section 2: > "Note also that the CGN described in this document is IPv4-only. > IPv6 address translation is not considered." > I see that this is a new change to the -07 version, so I hate to rehash the discussion, but I think that this statement should be clearer. > In reading the document, I don't believe that the intent was to limit it to being a discussion of NAT44[4], but that could be the way that this statement is interpreted. The distinction I might make to clarify is that since the document is talking about behaviors that are necessary to make IPv4 address-sharing work, it's specific to the IPv4 side of what could well be a dual-stack NAT, but it's not limited to simply NAT44[4]. > > I'm not advocating pulling this document back so that it can go to the "right" working group, because I don't think that'll actually add any value to the document and I'm not a fan of process for process's sake. My concern is really more about content and naming- if it is truly a IPv4-only NAT (NAT44 or NAT444) requirements doc rather than a more generic CGN requirements doc, it should be named to reflect that. If it's meant to be a generic LSN requirements doc, the authors should make the appropriate changes to keep it generic. > > Thanks, > > Wes George, at least partially wearing my Sunset4 chair hat -- 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 Jul 9 08:08:25 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 335D621F8517; Mon, 9 Jul 2012 08:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QB3rM8oax7sy; Mon, 9 Jul 2012 08:08: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 4B20021F8514; Mon, 9 Jul 2012 08:08:24 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c064:21aa:2a3f:6536:e26d]) by jazz.viagenie.ca (Postfix) with ESMTPSA id D951D415DA; Mon, 9 Jul 2012 11:08:48 -0400 (EDT) Message-ID: <4FFAF400.1030201@viagenie.ca> Date: Mon, 09 Jul 2012 11:08:48 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: "George, Wes" References: <4FF8A836.2090407@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "behave@ietf.org" , "ietf@ietf.org" , "sunset4@ietf.org" Subject: Re: [BEHAVE] Last Call: (Common requirements for Carrier Grade NATs (CGNs)) to Best Current Practice X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 15:08:25 -0000 On 2012-07-09 11:03, George, Wes wrote: > While the NAT specified by this > document itself may only act on IPv4 traffic, as you note above it's > not limited to just NAT444 or even an IPv4-only *network*. The > recommendations in this doc will work for an IPv4 NAT associated with > DSLite just as easily as a more traditional IPv4 transport. This is > an important distinction, IMO. Right, I understand now. It's the logical NAT function that is IPv4-only, not the global use case. I'll add some text to make this clear, and I'll specifically point out the DS-Lite example. >> How about "Common Requirements for IPv4 Carrier Grade NATs >> (CGNs)"? > [WEG] This helps, but only in conjunction with additional > clarification about the application - that is, just because the NAT > is IPv4-only doesn't mean that the network must also be IPv4-only. Understood. 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 liushucheng@huawei.com Tue Jul 10 02:12:36 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 045DA11E80A0 for ; Tue, 10 Jul 2012 02:12:36 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YU7JTQrhADQ4 for ; Tue, 10 Jul 2012 02:12:34 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id B520011E808E for ; Tue, 10 Jul 2012 02:12:34 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHW87827; Tue, 10 Jul 2012 05:13:01 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 10 Jul 2012 02:10:40 -0700 Received: from SZXEML438-HUB.china.huawei.com (10.72.61.73) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 10 Jul 2012 02:10:38 -0700 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.75]) by szxeml438-hub.china.huawei.com ([10.72.61.73]) with mapi id 14.01.0323.003; Tue, 10 Jul 2012 17:10:26 +0800 From: "Will Liu (Shucheng)" To: "behave@ietf.org" Thread-Topic: New Version Notification for draft-li-behave-nat444-test-00.txt Thread-Index: AQHNXdfAL8j28hZWeESjBzjnjQWiCpcg89lAgAFG31A= Date: Tue, 10 Jul 2012 09:10:26 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.79.130] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [BEHAVE] FW: New Version Notification for draft-li-behave-nat444-test-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 09:12:36 -0000 SGkgLCANCg0KV2UgaGF2ZSBzdWJtaXR0ZWQgYSBuZXcgZHJhZnQgZW50aXRsZWQgIiBOQVQ0NCBU cmFuc2xhdGlvbiBUZXN0aW5nIGluIFd1eGkgQnJhbmNoIG9mIENoaW5hIFRlbGVjb20iLiBUaGUg aW50ZW50IG9mIHRoZSBkcmFmdCBpcyB0byBkZXNjcmliZXMgdGhlIHRlc3RpbmcgcmVzdWx0IG9m IENHTiBkZXZpY2UgaW4gcmVhbCBuZXR3b3JrIGluIFd1eGkgQnJhbmNoIG9mIENoaW5hIFRlbGVj b20sIGJ5IHByb3ZpZGluZyBhbiBvdmVydmlldyBvZiBzdXBwb3J0IHNpdHVhdGlvbiBvZiBDR04g Zm9yIGdldHRpbmcgYXBwbGljYXRpb25zIHRocm91Z2ggTkFULiANCg0KVGhlIGxhdGVzdCB2ZXJz aW9uIGlzIGF2YWlsYWJsZSBhdDoNCjwgaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1saS1i ZWhhdmUtbmF0NDQ0LXRlc3QtMDAudHh0Pg0KDQpBbnkgY29tbWVudHMgd2lsbCBiZSBoaWdobHkg YXBwcmVjaWF0ZWQuDQoNClJlZ2FyZHMsDQpXaWxsIA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnXSANClNlbnQ6IE1vbmRheSwgSnVseSAwOSwgMjAxMiA5OjM1IFBNDQpUbzog V2lsbCBMaXUgKFNodWNoZW5nKQ0KQ2M6IGxpdWNodW5saW5AanNwdHBkLmNvbTsgWmhhbmd6b25n amlhbiAoVGhvbWFzKTsgMTUzMDYxODgyMTNAMTg5LmNuOyAxNTMwMTU4ODMzNkAxODkuY24NClN1 YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbGktYmVoYXZlLW5hdDQ0 NC10ZXN0LTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1saS1iZWhhdmUt bmF0NDQ0LXRlc3QtMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFdp bGwgTGl1IGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkg ZHJhZnQtbGktYmVoYXZlLW5hdDQ0NC10ZXN0DQpSZXZpc2lvbjoJIDAwDQpUaXRsZToJCSBOQVQ0 NCBUcmFuc2xhdGlvbiBUZXN0aW5nIGluIFd1eGkgQnJhbmNoIG9mIENoaW5hIFRlbGVjb20NCkNy ZWF0aW9uIGRhdGU6CSAyMDEyLTA3LTA5DQpXRyBJRDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24N Ck51bWJlciBvZiBwYWdlczogMzMNClVSTDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbGktYmVoYXZlLW5hdDQ0NC10ZXN0LTAwLnR4dA0KU3Rh dHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWxpLWJl aGF2ZS1uYXQ0NDQtdGVzdA0KSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1saS1iZWhhdmUtbmF0NDQ0LXRlc3QtMDANCg0KDQpBYnN0cmFjdDoNCiAgIFRo aXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSB0ZXN0aW5nIHJlc3VsdCBvZiBDR04gZGV2aWNlIGlu IFd1eGkNCiAgIEJyYW5jaCBvZiBDaGluYSBUZWxlY29tLCBieSBwcm92aWRpbmcgYW4gb3ZlcnZp ZXcgb2Ygc3RhdGUgYWJvdXQNCiAgIHN1cHBvcnRpbmcgYXBwbGljYXRpb25zIHRvIGFkYXB0IHRv IE5BVCBieSBDR04uICBUaGUgQ0dOIGRldmljZSBpcw0KICAgZnJvbSBIdWF3ZWkgYW5kIHRoZSB0 ZXN0IGVudmlyb25tZW50IGlzIHJlYWwgbmV0d29yayBpbiBXdXhpIENoaW5hLg0KDQoNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0K From meng.wei2@zte.com.cn Tue Jul 10 02:52:43 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D609521F875A for ; Tue, 10 Jul 2012 02:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.085 X-Spam-Level: X-Spam-Status: No, score=-100.085 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_DOUBLE_IP_LOOSE=0.76, 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 34c3qg31YjIF for ; Tue, 10 Jul 2012 02:52:43 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id E995F21F8723 for ; Tue, 10 Jul 2012 02:52:42 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 514961419759111; Tue, 10 Jul 2012 17:50:15 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 98428.1419759111; Tue, 10 Jul 2012 17:53:08 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q6A9qtJA084917 for ; Tue, 10 Jul 2012 17:52:55 +0800 (GMT-8) (envelope-from meng.wei2@zte.com.cn) In-Reply-To: To: Behave@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: meng.wei2@zte.com.cn Date: Tue, 10 Jul 2012 17:52:59 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-07-10 17:52:58, Serialize complete at 2012-07-10 17:52:58 Content-Type: multipart/alternative; boundary="=_alternative 0036499848257A37_=" X-MAIL: mse02.zte.com.cn q6A9qtJA084917 Subject: [BEHAVE] Two questions about draft-zhou-behave-syslog-nat-logging-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 09:52:44 -0000 This is a multipart message in MIME format. --=_alternative 0036499848257A37_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgIENoZW6jug0KDQogICBJIGhhdmUgcmVhZCB0aGUgZHJhZnQgYWJvdXQgTkFUIHN5c2xvZyBs b2dnaW5nLiBIZXJlIGFyZSB0d28gcXVlc3Rpb25zLg0KDQogICAxKSBJbiBzZWN0aW9uIDEuMSB5 b3Ugc3VtbWFyaXplIDQgc29sdXRpb24sIEkgdGhpbmsgdGhlIGNvbnRlbnQgb2YgDQpkcmFmdCBp cyBhYm91dCB0aGUgZmlyc3Qgc29sdXRpb24sIGFtIEkgcmlnaHQ/DQoNCiAgIDIpIFRoZSBkcmFm dCB3YW50cyB0byAgcHJlc2VudCB1cyBhIGtpbmQgb2YgbWVzc2FnZSBmb3JtYXQgb3IgZXZlbiBh IA0Ka2luZCBvZiBsb2cgZm9ybWF0IGFib3V0IE5BVCBzeXNsb2cgLiBJcyBpdCB0aGUga2V5IG9m IHRoZSB0ZXh0Pw0KDQpUaGFua3MsDQpXLiBNZW5nDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNl Y3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgKGFu ZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQg Y29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhl IGFkZHJlc3NlZShzKS4gIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55 IGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWlu YXRpb24gb3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJv aGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNl IGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0KDQo= --=_alternative 0036499848257A37_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpICZuYnNwO0NoZW6jujwvZm9u dD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNw O0kgaGF2ZSByZWFkIHRoZSBkcmFmdCBhYm91dA0KTkFUIHN5c2xvZyBsb2dnaW5nLiBIZXJlIGFy ZSB0d28gcXVlc3Rpb25zLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+Jm5ic3A7ICZuYnNwOzEpIEluIHNlY3Rpb24gMS4xIHlvdSBzdW1tYXJpemUNCjQg c29sdXRpb24sIEkgdGhpbmsgdGhlIGNvbnRlbnQgb2YgZHJhZnQgaXMgYWJvdXQgdGhlIGZpcnN0 IHNvbHV0aW9uLCBhbQ0KSSByaWdodD88L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsyKSBUaGUgZHJhZnQgd2FudHMgdG8gJm5ic3A7 cHJlc2VudA0KdXMgYSBraW5kIG9mIG1lc3NhZ2UgZm9ybWF0IG9yIGV2ZW4gYSBraW5kIG9mIGxv ZyBmb3JtYXQgYWJvdXQgTkFUIHN5c2xvZw0KLiBJcyBpdCB0aGUga2V5IG9mIHRoZSB0ZXh0Pzwv Zm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhhbmtzLDwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Vy4gTWVuZzwvZm9udD4N Cjxicj4NCjxicj48cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJz cDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtp biZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7KGFuZCZuYnNwO2FueSZuYnNwO2F0dGFjaG1lbnQm bmJzcDt0cmFuc21pdHRlZCZuYnNwO2hlcmV3aXRoKSZuYnNwO2lzJm5ic3A7cHJpdmlsZWdlZCZu YnNwO2FuZCZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2lzJm5ic3A7aW50ZW5kZWQm bmJzcDtmb3ImbmJzcDt0aGUmbmJzcDtleGNsdXNpdmUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3Ro ZSZuYnNwO2FkZHJlc3NlZShzKS4mbmJzcDsmbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2FyZSZuYnNw O25vdCZuYnNwO2FuJm5ic3A7aW50ZW5kZWQmbmJzcDtyZWNpcGllbnQsJm5ic3A7YW55Jm5ic3A7 ZGlzY2xvc3VyZSwmbmJzcDtyZXByb2R1Y3Rpb24sJm5ic3A7ZGlzdHJpYnV0aW9uJm5ic3A7b3Im bmJzcDtvdGhlciZuYnNwO2Rpc3NlbWluYXRpb24mbmJzcDtvciZuYnNwO3VzZSZuYnNwO29mJm5i c3A7dGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpcyZuYnNwO3N0cmlj dGx5Jm5ic3A7cHJvaGliaXRlZC4mbmJzcDsmbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJz cDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aW4mbmJzcDtlcnJvciwmbmJzcDtw bGVhc2UmbmJzcDtkZWxldGUmbmJzcDtpdCZuYnNwO2FuZCZuYnNwO25vdGlmeSZuYnNwO3VzJm5i c3A7aW1tZWRpYXRlbHkuDQoNCjwvcHJlPg== --=_alternative 0036499848257A37_=-- From j.schoenwaelder@jacobs-university.de Tue Jul 10 03:28:10 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAE021F85D8 for ; Tue, 10 Jul 2012 03:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.198 X-Spam-Level: X-Spam-Status: No, score=-103.198 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id goq8YITJCj3l for ; Tue, 10 Jul 2012 03:28:09 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 49E9921F85D2 for ; Tue, 10 Jul 2012 03:28:06 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3837020C23; Tue, 10 Jul 2012 12:28:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 01FHsmvKzHGZ; Tue, 10 Jul 2012 12:28:33 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BFAF520BC1; Tue, 10 Jul 2012 12:28:32 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 44F32204F643; Tue, 10 Jul 2012 12:28:30 +0200 (CEST) Date: Tue, 10 Jul 2012 12:28:30 +0200 From: Juergen Schoenwaelder To: meng.wei2@zte.com.cn Message-ID: <20120710102830.GA14694@elstar.local> Mail-Followup-To: meng.wei2@zte.com.cn, Behave@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Behave@ietf.org Subject: Re: [BEHAVE] Two questions about draft-zhou-behave-syslog-nat-logging-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 10:28:10 -0000 On Tue, Jul 10, 2012 at 05:52:59PM +0800, meng.wei2@zte.com.cn wrote: > Hi Chen： > > I have read the draft about NAT syslog logging. Here are two questions. > > 1) In section 1.1 you summarize 4 solution, I think the content of > draft is about the first solution, am I right? > > 2) The draft wants to present us a kind of message format or even a > kind of log format about NAT syslog . Is it the key of the text? > As far as I can tell, the I-D redefines RFC 5424 message formats (e.g. the TIMESTAMP in section 4.1.1.3), which is not appropriate. It also adds new supposedly machine readable content in an ad-hoc way (section 4.1.2) rather than defining proper structured data elements. I suggest to remove all text discussing RFC 5424 elements that do not (and must not) change and instead to focus on properly defining the new structured data elements considered useful for NATs. I can't comment on the RADIUS specific text but it might be useful to factor RADIUS specific things out into a separate document. The discussion of performance and reliability requirements likely does not belong into this document if it aims are being a technical protocol specification. Some of these requirements depend on deployment requirements or even legal frameworks. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From wesley.george@twcable.com Mon Jul 9 08:03:14 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A27B111E8087; Mon, 9 Jul 2012 08:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.722 X-Spam-Level: X-Spam-Status: No, score=-0.722 tagged_above=-999 required=5 tests=[AWL=-0.259, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 aL5MRFsC8WUY; Mon, 9 Jul 2012 08:03:13 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 339D911E8083; Mon, 9 Jul 2012 08:03:09 -0700 (PDT) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.77,552,1336363200"; d="scan'208";a="389825164" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 09 Jul 2012 11:03:01 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Mon, 9 Jul 2012 11:03:34 -0400 From: "George, Wes" To: Simon Perreault Date: Mon, 9 Jul 2012 11:03:32 -0400 Thread-Topic: Last Call: (Common requirements for Carrier Grade NATs (CGNs)) to Best Current Practice Thread-Index: Ac1chpQ7rIRV1kacS+6FyUAfZ7yjkQBXCS8A Message-ID: References: <4FF8A836.2090407@viagenie.ca> In-Reply-To: <4FF8A836.2090407@viagenie.ca> 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-Mailman-Approved-At: Tue, 10 Jul 2012 09:05:53 -0700 Cc: "behave@ietf.org" , "ietf@ietf.org" , "sunset4@ietf.org" Subject: Re: [BEHAVE] Last Call: (Common requirements for Carrier Grade NATs (CGNs)) to Best Current Practice X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 15:03:14 -0000 > From: Simon Perreault [mailto:simon.perreault@viagenie.ca] > Sent: Saturday, July 07, 2012 5:21 PM > > Wes, > > Here's my take on this... > > CGN as defined in this document does not only include NAT444. It is more > generic than that: it really means "multi-user NAT". Dave Thaler came up > with the example use case of the NAT in a wifi hotspot. It's just NAT44, > but it still fits with the draft's definition of CGN because you have > multiple users potentially fighting for the same NAT resources. Remember > that the main raison d'=EAtre of this draft is for the operator to be abl= e > to ensure fairness between NAT users. So in this view I think it is > clearly behave material since the sunsetting of IPv4 really is > orthogonal to multi-user NATs. > > On the question of IPv6: I don't think we should talk about IPv6 simply > because IPv6 NAT so far has not seen significant deployment in the > context of multi-user NAT. And NPTv6 is stateless so there are no > resources to fight for. [WEG] I agree with all of what you've said, but I think I need to make the = point that I'm concerned with clearer, because the above doesn't exactly ad= dress it. I wasn't saying anything about IPv6 NAT, or even IPv4 sunset. I w= as saying that the current wording is unclear as to what you mean by "IPv4-= only". While the NAT specified by this document itself may only act on IPv4= traffic, as you note above it's not limited to just NAT444 or even an IPv4= -only *network*. The recommendations in this doc will work for an IPv4 NAT = associated with DSLite just as easily as a more traditional IPv4 transport.= This is an important distinction, IMO. > > Back to your email, where you wrote: > > > if it is truly a IPv4-only NAT (NAT44 or NAT444) requirements doc > rather than a more generic CGN requirements doc, it should be named to > reflect that. > > How about "Common Requirements for IPv4 Carrier Grade NATs (CGNs)"? [WEG] This helps, but only in conjunction with additional clarification abo= ut the application - that is, just because the NAT is IPv4-only doesn't mea= n that the network must also be IPv4-only. Thanks Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From simon.perreault@viagenie.ca Tue Jul 10 12:55:29 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0C8711E814A for ; Tue, 10 Jul 2012 12:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.128, 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 FoL0WK9d78Ou for ; Tue, 10 Jul 2012 12:55:28 -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 CC5C811E8158 for ; Tue, 10 Jul 2012 12:55:28 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:8e70:5aff:fec5:72e4]) by jazz.viagenie.ca (Postfix) with ESMTPSA id B210844B4E for ; Tue, 10 Jul 2012 15:55:56 -0400 (EDT) Message-ID: <4FFC88CC.2090308@viagenie.ca> Date: Tue, 10 Jul 2012 15:55:56 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: behave@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [BEHAVE] New NAT MIB vs RFC4008 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 19:55:30 -0000 WG, For draft-ietf-behave-nat-mib, the most pressing thing we need to do is resolve the situation with regard to RFC4008. It looks to me like the best way forward is, as suggested by Dave Thaler, to merge our MIB with the one from RFC4008 and mark all the objects defined by RFC4008 with "STATUS deprecated". This would also solve the issue of naming because we could just drop the "new" prefix. Then we can tag our draft with "Obsoletes: 4008" and remove the paragraph about 4008 coexistence. Unless the WG disagrees, I'll do this before the Monday deadline. I will also remove the CGN-specific parts. They will hopefully progress in sunset4. Look for draft-perreault-sunset4-cgn-mib. 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 j.schoenwaelder@jacobs-university.de Tue Jul 10 14:26:48 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7090F11E8121 for ; Tue, 10 Jul 2012 14:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.199 X-Spam-Level: X-Spam-Status: No, score=-103.199 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ewvoLN9rmyk for ; Tue, 10 Jul 2012 14:26:47 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7B51A11E810B for ; Tue, 10 Jul 2012 14:26:47 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 77D2F20A9B; Tue, 10 Jul 2012 23:27:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id IKx8mkOSUHYx; Tue, 10 Jul 2012 23:27:15 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E946520979; Tue, 10 Jul 2012 23:27:14 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9CD1120507EC; Tue, 10 Jul 2012 23:27:13 +0200 (CEST) Date: Tue, 10 Jul 2012 23:27:13 +0200 From: Juergen Schoenwaelder To: Simon Perreault Message-ID: <20120710212713.GA16461@elstar.local> Mail-Followup-To: Simon Perreault , behave@ietf.org References: <4FFC88CC.2090308@viagenie.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FFC88CC.2090308@viagenie.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: behave@ietf.org Subject: Re: [BEHAVE] New NAT MIB vs RFC4008 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 21:26:48 -0000 On Tue, Jul 10, 2012 at 03:55:56PM -0400, Simon Perreault wrote: > WG, > > For draft-ietf-behave-nat-mib, the most pressing thing we need to do > is resolve the situation with regard to RFC4008. It looks to me like > the best way forward is, as suggested by Dave Thaler, to merge our > MIB with the one from RFC4008 and mark all the objects defined by > RFC4008 with "STATUS deprecated". This would also solve the issue of > naming because we could just drop the "new" prefix. Then we can tag > our draft with "Obsoletes: 4008" and remove the paragraph about 4008 > coexistence. > > Unless the WG disagrees, I'll do this before the Monday deadline. I first like to understand why RFC4008 is broken and why the new MIB is significantly better. If RFC4008 is indeed unfixably broken, it can be made historic and a new MIB can be produced. But this needs to be properly documented. As such, I suggest to focus on writing concise and clear text explaining why RFC4008 is so badly broken. And I would of course would like to hear as well the voices of those who shipped the RFC 4008 MIB in products. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From simon.perreault@viagenie.ca Tue Jul 10 15:43:26 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D13921F8547 for ; Tue, 10 Jul 2012 15:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, 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 FAyjItANxz04 for ; Tue, 10 Jul 2012 15:43:23 -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 3CCCC21F8532 for ; Tue, 10 Jul 2012 15:43:23 -0700 (PDT) Received: from porto.nomis80.org (modemcable212.59-179-173.mc.videotron.ca [173.179.59.212]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 8A65E44B4E for ; Tue, 10 Jul 2012 18:43:51 -0400 (EDT) Message-ID: <4FFCB026.9090906@viagenie.ca> Date: Tue, 10 Jul 2012 18:43:50 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: behave@ietf.org References: <4FFC88CC.2090308@viagenie.ca> <20120710212713.GA16461@elstar.local> In-Reply-To: <20120710212713.GA16461@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] New NAT MIB vs RFC4008 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 22:43:26 -0000 On 07/10/2012 05:27 PM, Juergen Schoenwaelder wrote: > I first like to understand why RFC4008 is broken and why the new MIB > is significantly better. If RFC4008 is indeed unfixably broken, it > can be made historic and a new MIB can be produced. But this needs to > be properly documented. As such, I suggest to focus on writing concise > and clear text explaining why RFC4008 is so badly broken. Will do. > And I would > of course would like to hear as well the voices of those who shipped > the RFC 4008 MIB in products. FWIW, Juniper in particular not only shipped RFC 4008 but also extended it. The fact that 4008 is present and used in the wild can be seen as one reason to mark stuff as deprecated rather than making the whole thing historic. 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 cathy.zhou@huawei.com Tue Jul 10 19:04:13 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B36A811E80A1 for ; Tue, 10 Jul 2012 19:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJb8SBYGuVAA for ; Tue, 10 Jul 2012 19:04:13 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id D2FB811E8072 for ; Tue, 10 Jul 2012 19:04:12 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHX47916; Tue, 10 Jul 2012 22:04:42 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 10 Jul 2012 19:02:34 -0700 Received: from SZXEML421-HUB.china.huawei.com (10.82.67.160) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 10 Jul 2012 19:02:38 -0700 Received: from SZXEML527-MBS.china.huawei.com ([169.254.6.143]) by szxeml421-hub.china.huawei.com ([10.82.67.160]) with mapi id 14.01.0323.003; Wed, 11 Jul 2012 10:02:34 +0800 From: "Zhouqian (Cathy)" To: Juergen Schoenwaelder , "meng.wei2@zte.com.cn" Thread-Topic: [BEHAVE] Two questions about draft-zhou-behave-syslog-nat-logging-00 Thread-Index: AQHNXoHts/v3GzCemECgO01H89kPKJchyl8AgACPtcA= Date: Wed, 11 Jul 2012 02:02:33 +0000 Message-ID: References: <20120710102830.GA14694@elstar.local> In-Reply-To: <20120710102830.GA14694@elstar.local> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.77.118] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "Behave@ietf.org" Subject: Re: [BEHAVE] Two questions about draft-zhou-behave-syslog-nat-logging-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 02:04:13 -0000 SGkgSnVlcmdlbiwNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogYmVoYXZl LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpiZWhhdmUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIEp1ZXJnZW4gU2Nob2Vud2FlbGRlcg0KU2VudDogVHVlc2RheSwgSnVseSAxMCwgMjAx MiA2OjI5IFBNDQpUbzogbWVuZy53ZWkyQHp0ZS5jb20uY24NCkNjOiBCZWhhdmVAaWV0Zi5vcmcN ClN1YmplY3Q6IFJlOiBbQkVIQVZFXSBUd28gcXVlc3Rpb25zIGFib3V0IGRyYWZ0LXpob3UtYmVo YXZlLXN5c2xvZy1uYXQtbG9nZ2luZy0wMA0KDQpPbiBUdWUsIEp1bCAxMCwgMjAxMiBhdCAwNTo1 Mjo1OVBNICswODAwLCBtZW5nLndlaTJAenRlLmNvbS5jbiB3cm90ZToNCj4gSGkgIENoZW7vvJoN Cj4gDQo+ICAgIEkgaGF2ZSByZWFkIHRoZSBkcmFmdCBhYm91dCBOQVQgc3lzbG9nIGxvZ2dpbmcu IEhlcmUgYXJlIHR3byBxdWVzdGlvbnMuDQo+IA0KPiAgICAxKSBJbiBzZWN0aW9uIDEuMSB5b3Ug c3VtbWFyaXplIDQgc29sdXRpb24sIEkgdGhpbmsgdGhlIGNvbnRlbnQgb2YgDQo+IGRyYWZ0IGlz IGFib3V0IHRoZSBmaXJzdCBzb2x1dGlvbiwgYW0gSSByaWdodD8NCj4gDQo+ICAgIDIpIFRoZSBk cmFmdCB3YW50cyB0byAgcHJlc2VudCB1cyBhIGtpbmQgb2YgbWVzc2FnZSBmb3JtYXQgb3IgZXZl biBhIA0KPiBraW5kIG9mIGxvZyBmb3JtYXQgYWJvdXQgTkFUIHN5c2xvZyAuIElzIGl0IHRoZSBr ZXkgb2YgdGhlIHRleHQ/DQo+IA0KDQpBcyBmYXIgYXMgSSBjYW4gdGVsbCwgdGhlIEktRCByZWRl ZmluZXMgUkZDIDU0MjQgbWVzc2FnZSBmb3JtYXRzDQooZS5nLiB0aGUgVElNRVNUQU1QIGluIHNl Y3Rpb24gNC4xLjEuMyksIHdoaWNoIGlzIG5vdCBhcHByb3ByaWF0ZS4gSXQNCmFsc28gYWRkcyBu ZXcgc3VwcG9zZWRseSBtYWNoaW5lIHJlYWRhYmxlIGNvbnRlbnQgaW4gYW4gYWQtaG9jIHdheQ0K KHNlY3Rpb24gNC4xLjIpIHJhdGhlciB0aGFuIGRlZmluaW5nIHByb3BlciBzdHJ1Y3R1cmVkIGRh dGENCmVsZW1lbnRzLiBJIHN1Z2dlc3QgdG8gcmVtb3ZlIGFsbCB0ZXh0IGRpc2N1c3NpbmcgUkZD IDU0MjQgZWxlbWVudHMNCnRoYXQgZG8gbm90IChhbmQgbXVzdCBub3QpIGNoYW5nZSBhbmQgaW5z dGVhZCB0byBmb2N1cyBvbiBwcm9wZXJseQ0KZGVmaW5pbmcgdGhlIG5ldyBzdHJ1Y3R1cmVkIGRh dGEgZWxlbWVudHMgY29uc2lkZXJlZCB1c2VmdWwgZm9yIE5BVHMuDQpDYXRoeTogVGhhbmtzIGZv ciB5b3VyIGNvbW1lbnRzLCBhbmQgeW91IGFyZSByaWdodC4gV2Ugd2lsbCB1cGRhdGUgaXQuDQoN CkkgY2FuJ3QgY29tbWVudCBvbiB0aGUgUkFESVVTIHNwZWNpZmljIHRleHQgYnV0IGl0IG1pZ2h0 IGJlIHVzZWZ1bCB0bw0KZmFjdG9yIFJBRElVUyBzcGVjaWZpYyB0aGluZ3Mgb3V0IGludG8gYSBz ZXBhcmF0ZSBkb2N1bWVudC4NCkNhdGh5OiBXZSBjYW4ga2VlcCB0aGlzIHNlY3Rpb24gYW5kIGdl dCBzcGVjaWZpYyBleHRlbnNpb25zIG91dCBvZiB0aGUgZG9jdW1lbnQuDQoNClRoZSBkaXNjdXNz aW9uIG9mIHBlcmZvcm1hbmNlIGFuZCByZWxpYWJpbGl0eSByZXF1aXJlbWVudHMgbGlrZWx5IGRv ZXMNCm5vdCBiZWxvbmcgaW50byB0aGlzIGRvY3VtZW50IGlmIGl0IGFpbXMgYXJlIGJlaW5nIGEg dGVjaG5pY2FsDQpwcm90b2NvbCBzcGVjaWZpY2F0aW9uLiBTb21lIG9mIHRoZXNlIHJlcXVpcmVt ZW50cyBkZXBlbmQgb24NCmRlcGxveW1lbnQgcmVxdWlyZW1lbnRzIG9yIGV2ZW4gbGVnYWwgZnJh bWV3b3Jrcy4NCkNhdGh5OiBJIGFtIGFsc28gbm90IHN1cmUgaWYgaXQgaXMgYXBwcm9wcmlhdGUg dG8gcHV0IHRoZSBwZXJmb3JtYW5jZSByZXF1aXJlbWVudHMgaGVyZS4gDQpNeSBpbnRlbnRpb24g aXMgdG8gcHJvdmlkZSBzb21lIGd1aWRlcyBmb3IgZGVwbG95bWVudC4NCg0KQ2F0aHkgDQogDQov anMNCg0KLS0gDQpKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJz aXR5IEJyZW1lbiBnR21iSA0KUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMg UmluZyAxLCAyODc1OSBCcmVtZW4sIEdlcm1hbnkNCkZheDogICArNDkgNDIxIDIwMCAzMTAzICAg ICAgICAgPGh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkJlaGF2ZSBtYWlsaW5nIGxpc3QNCkJl aGF2ZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9iZWhh dmUNCg== From Tina.Tsou.Zouting@huawei.com Tue Jul 10 19:46:21 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA40C11E80E0; Tue, 10 Jul 2012 19:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.882 X-Spam-Level: X-Spam-Status: No, score=-5.882 tagged_above=-999 required=5 tests=[AWL=0.716, 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 G2PMY5Rk5pZ8; Tue, 10 Jul 2012 19:46:21 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id B5BAB11E8079; Tue, 10 Jul 2012 19:46:20 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHX50059; Tue, 10 Jul 2012 22:46:50 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 10 Jul 2012 19:43:30 -0700 Received: from dfweml513-mbx.china.huawei.com ([169.254.3.208]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.003; Tue, 10 Jul 2012 19:43:30 -0700 From: Tina TSOU To: Simon Perreault Thread-Topic: [sunset4] Last Call: (Common requirements for Carrier Grade NATs (CGNs)) to Best Current Practice Thread-Index: AQHNXeQa9cn4jo2TiUil16mU5pbaQpchgwsAgAHfFr4= Date: Wed, 11 Jul 2012 02:43:30 +0000 Message-ID: <1DF204BC-FAD6-4A0E-90B0-64760CC1ECF9@huawei.com> References: <4FF8A836.2090407@viagenie.ca> , <4FFAF400.1030201@viagenie.ca> In-Reply-To: <4FFAF400.1030201@viagenie.ca> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_1DF204BCFAD64A0E90B064760CC1ECF9huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "sunset4@ietf.org" , "behave@ietf.org" , "ietf@ietf.org" , "George, Wes" Subject: Re: [BEHAVE] [sunset4] Last Call: (Common requirements for Carrier Grade NATs (CGNs)) to Best Current Practice X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jul 2012 02:46:22 -0000 --_000_1DF204BCFAD64A0E90B064760CC1ECF9huaweicom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable There are few things that in my opinion should be added. First, the port numbers to be allocated to CPE. Excluding Well known port n= umbers should be mentioned. Moreover if port numbers are allocated to each = CPE, what is the criteria for allocation. As mentioned in the document : = =93 There should be no limit on the size of the address pool=94, does this = address pool imply the one that would be allocated to the CPE? According to= the requirement of the CPE, the pool should be allocated or a fixed number= of addresses in the address pool should be allocated to each CPE? Some amo= unt of clarity in this respect would be helpful. Moreover, the document advocates the use of Endpoint independent filtering.= If AID is used, there would be a delay of 120 seconds for each port reallo= cation. So should EIF be used only with those applications that can=92t fun= ction without it, instead of applying it for all. The need to maintain a record or database of the allocated ports and their = lifetime would be helpful. If this is maintained, the ports that are near t= o expiring their lifetime would be considered first and allocated before an= d in a order. In such cases there will be less chances of the traffic being= dropped due to ports not being available. There should be a definite lifet= ime defined, before connection is refused due to unavailability of ports. I= f there is a threshold of say,180 seconds, during which allocated ports dat= abase can be scanned and if any ports is recently available, can be allocat= ed. This would lead to efficient use of ports. Tina On Jul 9, 2012, at 8:08 AM, "Simon Perreault" > wrote: On 2012-07-09 11:03, George, Wes wrote: While the NAT specified by this document itself may only act on IPv4 traffic, as you note above it's not limited to just NAT444 or even an IPv4-only *network*. The recommendations in this doc will work for an IPv4 NAT associated with DSLite just as easily as a more traditional IPv4 transport. This is an important distinction, IMO. Right, I understand now. It's the logical NAT function that is IPv4-only, n= ot the global use case. I'll add some text to make this clear, and I'll spe= cifically point out the DS-Lite example. How about "Common Requirements for IPv4 Carrier Grade NATs (CGNs)"? [WEG] This helps, but only in conjunction with additional clarification about the application - that is, just because the NAT is IPv4-only doesn't mean that the network must also be IPv4-only. Understood. 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 _______________________________________________ sunset4 mailing list sunset4@ietf.org https://www.ietf.org/mailman/listinfo/sunset4 --_000_1DF204BCFAD64A0E90B064760CC1ECF9huaweicom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
There are few things that in my opinion should be added.<= /div>
 
First, the port numbers to be allocated to CPE. Excluding Well known p= ort numbers should be mentioned. Moreover if port numbers are allocated to = each CPE, what is the criteria for allocation. As mentioned in the document= : =93 There should be no limit on the size of the address pool=94, does this address pool imply the one that= would be allocated to the CPE? According to the requirement of the CPE, th= e pool should be allocated or a fixed number of addresses in the address po= ol should be allocated to each CPE? Some amount of clarity in this respect would be helpful.
 
Moreover, the document advocates the use of Endpoint independent filte= ring. If AID is used, there would be a delay of 120 seconds for each port r= eallocation. So should EIF be used only with those applications that can=92= t function without it, instead of applying it for all.
 
The need to maintain a record or database of the allocated ports= and their lifetime would be helpful. If this is maintained, the ports that= are near to expiring their lifetime would be considered first and allocate= d before and in a order. In such cases there will be less chances of the traffic being dropped due to ports= not being available. There should be a definite lifetime defined, before c= onnection is refused due to unavailability of ports. If there is a threshol= d of say,180 seconds, during which allocated ports database can be scanned and if any ports is recently avail= able, can be allocated. This would lead to efficient use of ports.
Tina

On Jul 9, 2012, at 8:08 AM, "Simon Perreault" <simon.perreault@viagenie.ca> wrote:<= br>
On 2012-07-09 11:03, George, Wes wrote:
While the NAT specified by this
document itself may only act on IPv4 traffi= c, as you note above it's
not limited to just NAT444 or even an IPv4-= only *network*. The
recommendations in this doc will work for a= n IPv4 NAT associated with
DSLite just as easily as a more traditional= IPv4 transport. This is
an important distinction, IMO.

Right, I understand now. It's the logical NAT function that is IPv4-o= nly, not the global use case. I'll add some text to make this clear, and I'= ll specifically point out the DS-Lite example.

How about "Common Requirements for IPv= 4 Carrier Grade NATs
(CGNs)"?
[WEG] This helps, but only in conjunction w= ith additional
clarification about the application - that = is, just because the NAT
is IPv4-only doesn't mean that the network = must also be IPv4-only.

Understood.

Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --&= gt; http://ecdysis.viagenie.ca
STUN/TURN server         &nbs= p;     --> = http://numb.viagenie.ca
_______________________________________________
sunset4 mailing list
sunset4@ietf.org
https://www= .ietf.org/mailman/listinfo/sunset4
--_000_1DF204BCFAD64A0E90B064760CC1ECF9huaweicom_-- From zhangzhongjian@huawei.com Tue Jul 10 20:41:55 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F30D711E80C1 for ; Tue, 10 Jul 2012 20:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PN77fpvm7wAO for ; Tue, 10 Jul 2012 20:41:54 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 59F7111E8079 for ; Tue, 10 Jul 2012 20:41:54 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHX52822; Tue, 10 Jul 2012 23:42:23 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 10 Jul 2012 20:39:55 -0700 Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 10 Jul 2012 20:39:53 -0700 Received: from SZXEML524-MBS.china.huawei.com ([169.254.5.229]) by szxeml413-hub.china.huawei.com ([10.82.67.152]) with mapi id 14.01.0323.003; Wed, 11 Jul 2012 11:39:45 +0800 From: "Zhangzongjian (Thomas)" To: Dan Wing , "draft-li-behave-nat444-test@tools.ietf.org" , "15301588336@189.cn" <15301588336@189.cn>, "15306188213@189.cn" <15306188213@189.cn>, "liuchunlin@jsptpd.com" , "Will Liu (Shucheng)" Thread-Topic: comment on draft-li-behave-nat444-test-00, FTP active/passive Thread-Index: Ac1e+4L5W6hTgdXpSUKgVBZ9YLoKkgAGaJ/w Date: Wed, 11 Jul 2012 03:39:44 +0000 Message-ID: <0B2F754289D27B449F7F1B95456B77544EDB63D7@szxeml524-mbs.china.huawei.com> References: <085801cd5efb$8344aa50$89cdfef0$@com> In-Reply-To: <085801cd5efb$8344aa50$89cdfef0$@com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.77.96] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "behave@ietf.org" Subject: Re: [BEHAVE] comment on draft-li-behave-nat444-test-00, FTP active/passive X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jul 2012 03:41:55 -0000 Dear Dan In fact we tested the typical FTP active model as an illustration for the F= TP scenarios. In such an example, the FTP server is in public networks and = FTP client is in private network. Thanks for your comments. We will add the= detailed description in the next version. Thomas Best regards -----Original Message----- From: Dan Wing [mailto:dwing@cisco.com]=20 Sent: Wednesday, July 11, 2012 8:24 AM To: draft-li-behave-nat444-test@tools.ietf.org; 15301588336@189.cn; 1530618= 8213@189.cn; liuchunlin@jsptpd.com; Will Liu (Shucheng); Zhangzongjian (Tho= mas) Subject: comment on draft-li-behave-nat444-test-00, FTP active/passive Hi. It would be helpful in your FTP test results if you indicated if passive (PASV) or active mode was tested. -d From czh7@21cn.com Tue Jul 10 22:41:36 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 011E711E80D5 for ; Tue, 10 Jul 2012 22:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_73=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 igWBgFZoKt1A for ; Tue, 10 Jul 2012 22:41:35 -0700 (PDT) Received: from 21cn.com (smtpfree.forptr.21cn.com [59.36.102.43]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8C111E80BA for ; Tue, 10 Jul 2012 22:41:35 -0700 (PDT) HMM_SOURCE_IP: 10.27.2.13:48169.597865428 HMM_ATTACHE_NUM: 0000 HMM_SOURCE_TYPE: SMTP Received: from chenzhonghua-nb (unknown [10.27.2.13]) by 21cn.com (HERMES) with ESMTP id 580023846D; Wed, 11 Jul 2012 13:40:57 +0800 (CST) Received: from chenzhonghua-nb ([115.238.45.234]) by 21CN-Medusa4(MEDUSA 10.27.2.13) with ESMTP id 1341985255.7434 for meng.wei2@zte.com.cn ; Wed Jul 11 13:40:59 2012 0/X-Brightmail-Tracker: AAAAAA== 1/X-Total-Score: 0: 3/X-Total-Score: 0: X-FILTER-SCORE: to=<8e868f884f98868a53619b95864f84908e4f848f8e868f884f98868a53619b95864f84908e4f848f838689829786618a8695874f909388>, score=<1341985259zjzJYjpQGIdBzzzzzJzzYzmpaym1KQPt4pppppappypp> Date: Wed, 11 Jul 2012 13:40:57 +0800 From: "chen" To: "meng.wei2" , "meng.wei2" Message-ID: <201207111340550008526@21cn.com> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Cc: behave Subject: Re: [BEHAVE] Two questions about draft-zhou-behave-syslog-nat-logging-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 05:49:52 -0000 HI meng.wei2: you are right. we just talk about the first solution in this version. because it's a mature solution ,and we already used it in our network.but we still want to make a discussion on other three methods. For it will be useful in some cases. Syslog format is just for solution 1.We will need other protocol for other solutions. chen czh7@21cn.com 2012-07-11 From miyakawa@nttv6.jp Wed Jul 11 00:34:18 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3B3121F858A; Wed, 11 Jul 2012 00:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.787 X-Spam-Level: X-Spam-Status: No, score=0.787 tagged_above=-999 required=5 tests=[AWL=-0.877, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_BASE64_TEXT=1.753] 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 ywl6ZuZRSUlV; Wed, 11 Jul 2012 00:34:18 -0700 (PDT) Received: from guri.nttv6.jp (guri.nttv6.jp [IPv6:2402:c800:ff06:144::148]) by ietfa.amsl.com (Postfix) with ESMTP id 0AEE221F85DF; Wed, 11 Jul 2012 00:34:17 -0700 (PDT) Received: from z.nttv6.jp (z.nttv6.jp [115.69.228.212]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id B1B75BDC1E; Wed, 11 Jul 2012 16:34:44 +0900 (JST) Received: from localhost (localhost [IPv6:::1]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 853F7E169A; Wed, 11 Jul 2012 16:34:44 +0900 (JST) Date: Wed, 11 Jul 2012 16:34:44 +0900 (JST) Message-Id: <20120711.163444.104075113.miyakawa@nttv6.jp> To: Tina.Tsou.Zouting@huawei.com From: Shin Miyakawa In-Reply-To: <1DF204BC-FAD6-4A0E-90B0-64760CC1ECF9@huawei.com> References: <4FFAF400.1030201@viagenie.ca> <1DF204BC-FAD6-4A0E-90B0-64760CC1ECF9@huawei.com> Organizaton: NTT Communications X-Mailer: Mew version 6.3 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-7 Content-Transfer-Encoding: base64 Cc: behave@ietf.org, ietf@ietf.org, wesley.george@twcable.com, sunset4@ietf.org, miyakawa@nttv6.jp Subject: Re: [BEHAVE] [sunset4] Last Call: (Common requirements for Carrier Grade NATs (CGNs)) to Best Current Practice X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jul 2012 07:34:18 -0000 VGluYSwNCg0KVGhhbmtzIGZvciB0aGUgY29tbWVudC4gDQoNCj4gRmlyc3QsIHRoZSBwb3J0IG51 bWJlcnMgdG8gYmUgYWxsb2NhdGVkIHRvIENQRS4gRXhjbHVkaW5nIFdlbGwga25vd24gcG9ydCBu dW1iZXJzIHNob3VsZCBiZSBtZW50aW9uZWQuIA0KDQpJIHRoaW5rIHRoYXQgZXZlbiBpZiB3ZWxs IGtub3cgcG9ydCBpcyBhbGxvY2F0ZWQgYXMgc3JjIGFkZHJlc3MsIA0KdGhlcmUgd291bGQgYmUg bm8gcHJvYmxlbS4gDQpUaGUgZG9jdW1lbnQgaXMgYWltaW5nIGF0ICJtaW5pbWFsIiBzZXQgb2Yg cmVxdWlyZW1lbnRzIHRvIG1ha2UgQ0dOIHRyYW5zcGFyZW50LCANCkkgYWdyZWUgd2l0aCB0aGF0 IHRoaXMgY291bGQgYmUgaGVscGZ1bCANCmJ1dCBJIGRvbid0IHRoaW5rIHRoaXMgaXMgYSBjcml0 aWNhbCBjb25kaXRpb24gdG8gbWFrZSB0aGlzIEktRCBhbiBSRkMsIGlzbid0IGl0ID8NCg0KPiBN b3Jlb3ZlciBpZiBwb3J0IG51bWJlcnMgYXJlIGFsbG9jYXRlZCB0byBlYWNoIENQRSwgd2hhdCBp cyB0aGUgY3JpdGVyaWEgZm9yIGFsbG9jYXRpb24uIA0KDQpJIHRoaW5rIHRoYXQgaXQncyBvcGVy YXRvcnMnIGNob2ljZSA6LSkNCg0KPHNuaXA+DQoNCj4gU29tZSBhbW91bnQgb2YgY2xhcml0eSBp biB0aGlzIHJlc3BlY3Qgd291bGQgYmUgaGVscGZ1bC4NCg0KSSBhbHNvIHRoaW5rIHRoaXMga2lu ZCBvZiBpbmZvcm1hdGlvbiBpcyB1c3VmdWwsIGJ1dCANCnRoaXMgY291bGQgYmUgZGlzY3Vzc2Vk IGluIG90aGVyIGRyYWZ0IGlzbid0IGl0ID8NCg0KPiBNb3Jlb3ZlciwgdGhlIGRvY3VtZW50IGFk dm9jYXRlcyB0aGUgdXNlIG9mIEVuZHBvaW50IGluZGVwZW5kZW50IGZpbHRlcmluZy4gSWYgQUlE IGlzIHVzZWQsIHRoZXJlIHdvdWxkIGJlIGEgZGVsYXkgb2YgMTIwIHNlY29uZHMgZm9yIGVhY2gg cG9ydCByZWFsbG9jYXRpb24uIFNvIHNob3VsZCBFSUYgYmUgdXNlZCBvbmx5IHdpdGggdGhvc2Ug YXBwbGljYXRpb25zIHRoYXQgY2FuonQgZnVuY3Rpb24gd2l0aG91dCBpdCwgaW5zdGVhZCBvZiBh cHBseWluZyBpdCBmb3IgYWxsLg0KDQpJIHNlZS4uLiBFc3BlY2lhbGx5LCBTaW1vbiwgaG93IGRv IHlvdSB0aGluayA/DQoNCj4gDQo+IFRoZSBuZWVkIHRvIG1haW50YWluIGEgcmVjb3JkIG9yIGRh dGFiYXNlIG9mIHRoZSBhbGxvY2F0ZWQgcG9ydHMgYW5kIHRoZWlyIGxpZmV0aW1lIHdvdWxkIGJl IGhlbHBmdWwuIA0KDQpGb3IgZXhhbXBsZSwgaWYgcG9ydCBpcyBzdGF0aWNhbGx5IGFzc2lnbmVk LCB0aGVyZSBpcyBubyBuZWVkIHRvIGhhdmUgDQpzdWNoIHJlY29yZC4gU28sIGFnYWluLCBJIGFn cmVlIHdpdGggdGhhdCB0aGlzIGlzIG9mIGNvdXJzZSBhIGNsdWUgdG8gDQpvcGVyYXRlIENHTiBi ZXR0ZXIgaW4gY2VydGFpbiBlbnZpcm9ubWVudCwgYnV0IHN0aWxsIGlzIG5vdCBhIGNyaXRpY2Fs LCBJIHRoaW5rLg0KDQpTbywgaG93IGFib3V0IHdlIGNvdWxkIGNyZWF0ZSBhIGRvY3VtZW50IHdp dGggc3VjaCBhIGhpbnQgZm9yIENHTiBvcGVyYXRpb24gDQpzZXByYXRlbHkgdGhlbiBsZXQgdGhp cyBJLUQgbW92ZSBmb3J3YXJkIG5vdyA/ID4gVGluYQ0KDQpCZXN0IHdpc2hlcywNCg0KU2hpbiBN aXlha2F3YSANCg0K From liushucheng@huawei.com Wed Jul 11 01:46:53 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F2E321F8602 for ; Wed, 11 Jul 2012 01:46:53 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id itcgXBNxKvIA for ; Wed, 11 Jul 2012 01:46:52 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 51D8821F8607 for ; Wed, 11 Jul 2012 01:46:52 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHX70339; Wed, 11 Jul 2012 04:47:22 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 11 Jul 2012 01:44:37 -0700 Received: from SZXEML432-HUB.china.huawei.com (10.72.61.60) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 11 Jul 2012 01:44:36 -0700 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.75]) by SZXEML432-HUB.china.huawei.com ([10.72.61.60]) with mapi id 14.01.0323.003; Wed, 11 Jul 2012 16:44:27 +0800 From: "Will Liu (Shucheng)" To: "Zhangzongjian (Thomas)" , Dan Wing , "draft-li-behave-nat444-test@tools.ietf.org" , "15301588336@189.cn" <15301588336@189.cn>, "15306188213@189.cn" <15306188213@189.cn>, "liuchunlin@jsptpd.com" Thread-Topic: comment on draft-li-behave-nat444-test-00, FTP active/passive Thread-Index: Ac1e+4L5W6hTgdXpSUKgVBZ9YLoKkgAGaJ/wAAVbFxA= Date: Wed, 11 Jul 2012 08:44:26 +0000 Message-ID: References: <085801cd5efb$8344aa50$89cdfef0$@com> <0B2F754289D27B449F7F1B95456B77544EDB63D7@szxeml524-mbs.china.huawei.com> In-Reply-To: <0B2F754289D27B449F7F1B95456B77544EDB63D7@szxeml524-mbs.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.79.130] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "behave@ietf.org" Subject: Re: [BEHAVE] comment on draft-li-behave-nat444-test-00, FTP active/passive X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jul 2012 08:46:53 -0000 Hi, One thing I would like to add here is, this draft mainly focuses on the div= ersity of application tested. What we listed in the draft basically covers = almost all the current typical popular applications. By posting this draft,= we are able to show the outline of support situation of CGN for getting va= st majority of applications through NAT, to both network man as well as tho= se who are also interested in network software development. There might sti= ll be some scenarios we have not covered. If anybody is interested in those= we did not mention in our draft, we are appreciated to your comments. Have a nice day! Will -----Original Message----- From: Zhangzongjian (Thomas)=20 Sent: Wednesday, July 11, 2012 11:40 AM To: Dan Wing; draft-li-behave-nat444-test@tools.ietf.org; 15301588336@189.c= n; 15306188213@189.cn; liuchunlin@jsptpd.com; Will Liu (Shucheng) Cc: behave@ietf.org Subject: RE: comment on draft-li-behave-nat444-test-00, FTP active/passive Dear Dan In fact we tested the typical FTP active model as an illustration for the F= TP scenarios. In such an example, the FTP server is in public networks and = FTP client is in private network. Thanks for your comments. We will add the= detailed description in the next version. Thomas Best regards -----Original Message----- From: Dan Wing [mailto:dwing@cisco.com]=20 Sent: Wednesday, July 11, 2012 8:24 AM To: draft-li-behave-nat444-test@tools.ietf.org; 15301588336@189.cn; 1530618= 8213@189.cn; liuchunlin@jsptpd.com; Will Liu (Shucheng); Zhangzongjian (Tho= mas) Subject: comment on draft-li-behave-nat444-test-00, FTP active/passive Hi. It would be helpful in your FTP test results if you indicated if passive (PASV) or active mode was tested. -d From simon.perreault@viagenie.ca Wed Jul 11 07:00:44 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C273221F8666; Wed, 11 Jul 2012 07:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALqVd3apM04E; Wed, 11 Jul 2012 07:00:43 -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 AD06621F865A; Wed, 11 Jul 2012 07:00:43 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:8e70:5aff:fec5:72e4]) by jazz.viagenie.ca (Postfix) with ESMTPSA id BC5CF414AC; Wed, 11 Jul 2012 10:01:11 -0400 (EDT) Message-ID: <4FFD8727.4020207@viagenie.ca> Date: Wed, 11 Jul 2012 10:01:11 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Tina TSOU References: <4FF8A836.2090407@viagenie.ca> , <4FFAF400.1030201@viagenie.ca> <1DF204BC-FAD6-4A0E-90B0-64760CC1ECF9@huawei.com> In-Reply-To: <1DF204BC-FAD6-4A0E-90B0-64760CC1ECF9@huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "sunset4@ietf.org" , "behave@ietf.org" , "ietf@ietf.org" , "George, Wes" Subject: Re: [BEHAVE] [sunset4] Last Call: (Common requirements for Carrier Grade NATs (CGNs)) to Best Current Practice X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jul 2012 14:00:44 -0000 On 07/10/2012 10:43 PM, Tina TSOU wrote: > First, the port numbers to be allocated to CPE. Excluding Well known > port numbers should be mentioned. As draft editor, I would ask for a justification. I can't add a requirement without a justification. > Moreover if port numbers are allocated > to each CPE, what is the criteria for allocation. I don't know, I'm just an editor. What specific text in the draft do you think needs to be changed? > As mentioned in the > document : “ There should be no limit on the size of the address pool”, > does this address pool imply the one that would be allocated to the CPE? No. It refers to the external address pool used by the CGN. > According to the requirement of the CPE, the pool should be allocated or > a fixed number of addresses in the address pool should be allocated to > each CPE? Sorry, I don't understand this question. > Moreover, the document advocates the use of Endpoint independent > filtering. If AID is used, there would be a delay of 120 seconds for > each port reallocation. So should EIF be used only with those > applications that can’t function without it, instead of applying it for all. The draft proposes a more conservative approach: use EIF for everything with ADF exceptions. I understand you propose the reverse: ADF for everything with EIF exceptions. And I understand that the justification would be scalability. However, it seems to me that ADF exceptions can be made for heavy use protocols such as HTTP and DNS to address that scalability concern. Why isn't that enough? > The need to maintain a record or database of the allocated ports and > their lifetime would be helpful. How could any NAT work without such a database? I probably misunderstand what you're suggesting... > If this is maintained, the ports that > are near to expiring their lifetime would be considered first and > allocated before and in a order. In such cases there will be less > chances of the traffic being dropped due to ports not being available. This seems to go against REQ-11 D. REQ-11: When a CGN is unable to create a mapping due to resource constraints or administrative restrictions (i.e., quotas): D. and it MUST NOT delete existing mappings in order to "make room" for the new one. (This only applies to normal CGN behavior, not to manual operator intervention.) Are you suggesting that this requirement be dropped? If so, it would be necessary to demonstrate why the justification for this requirement, quoted below, is invalid. Applications generally handle connection establishment failure better than established connection failure. This is why dropping the packet initiating the new connection is preferred over deleting existing mappings. See also the rationale in [RFC5508] section 6. > There should be a definite lifetime defined, before connection is > refused due to unavailability of ports. If there is a threshold of > say,180 seconds, during which allocated ports database can be scanned > and if any ports is recently available, can be allocated. This would > lead to efficient use of ports. I'm sorry, I don't understand this proposal. Maybe an example would help? Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From dwing@cisco.com Wed Jul 11 08:07:26 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B497621F8555 for ; Wed, 11 Jul 2012 08:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.469 X-Spam-Level: X-Spam-Status: No, score=-110.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 djdzHx4thJU1 for ; Wed, 11 Jul 2012 08:07:25 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id E8FF121F852D for ; Wed, 11 Jul 2012 08:07:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2297; q=dns/txt; s=iport; t=1342019277; x=1343228877; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=QX7lXzp9IKhO3l1dmqpGBgmFP02KnOWbyh1njDFl2LU=; b=W9W8IAhH+p8o7oEl+HmX6xS2Mx1JKtE2VxAPY0fXsO7zj/3wiuHnywcO H1a5fCbbKw18J7m/LOUYOXvcEhkFixO8y4ELqiHwUuGGT2BLzHIoCXnca t/onTfqY/2NgQqVu6SrsVmbywH+599GQ3zHumLcqW/ES7Rj/K/+qeuZHm 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAFWW/U+rRDoJ/2dsb2JhbABFqDuPKoEHgiABAQEDAQEBAQUKARcQNAsFBwEDAgkPAgQBASgHGQ4VCgkIAQEEARILF4dlBQydQqAdBItAhW4DiEuFBZYKgWaCfw X-IronPort-AV: E=Sophos;i="4.77,567,1336348800"; d="scan'208";a="49073039" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 11 Jul 2012 15:07:56 +0000 Received: from dwingWS (sjc-vpn5-356.cisco.com [10.21.89.100]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q6BF7uD2031754; Wed, 11 Jul 2012 15:07:56 GMT From: "Dan Wing" To: "'Zhangzongjian \(Thomas\)'" , , <15301588336@189.cn>, <15306188213@189.cn>, , "'Will Liu \(Shucheng\)'" References: <085801cd5efb$8344aa50$89cdfef0$@com> <0B2F754289D27B449F7F1B95456B77544EDB63D7@szxeml524-mbs.china.huawei.com> In-Reply-To: <0B2F754289D27B449F7F1B95456B77544EDB63D7@szxeml524-mbs.china.huawei.com> Date: Wed, 11 Jul 2012 08:07:56 -0700 Message-ID: <09b901cd5f76$f3ccfe50$db66faf0$@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: Ac1e+4L5W6hTgdXpSUKgVBZ9YLoKkgAGaJ/wABgzjYA= Content-Language: en-us Cc: behave@ietf.org Subject: Re: [BEHAVE] comment on draft-li-behave-nat444-test-00, FTP active/passive X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jul 2012 15:07:26 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Zhangzongjian (Thomas) > Sent: Tuesday, July 10, 2012 8:40 PM > To: Dan Wing; draft-li-behave-nat444-test@tools.ietf.org; > 15301588336@189.cn; 15306188213@189.cn; liuchunlin@jsptpd.com; Will Liu > (Shucheng) > Cc: behave@ietf.org > Subject: Re: [BEHAVE] comment on draft-li-behave-nat444-test-00, FTP > active/passive > > Dear Dan > In fact we tested the typical FTP active model as an illustration for > the FTP scenarios. My statistics show that active FTP is not typical. Several years ago I obtained logs from ftp.cisco.com and 99% of our connections were passive-mode FTP. It was only one user, downloading several files, that was using active-mode FTP, and had an IP address belonging to Boeing. All web browsers do passive-mode FTP by default or exclusively, including IE 7 and up, Safari, Firefox, Opera, and Chrome. Do you have statistics showing a high number of active mode FTP? Perhaps this is caused by IE 6, which I know is still used extensively in China, and defaults to active-mode FTP. It would be interesting to know how often active mode FTP is used considering it would also require FTP ALG support in existing WiFi access points (restaurants, hotels, and airports). > In such an example, the FTP server is in public > networks and FTP client is in private network. Thanks for your > comments. We will add the detailed description in the next version. Thanks, that would be helpful. As you know, passive FTP does not need an FTP ALG. -d > Thomas > Best regards > > > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Wednesday, July 11, 2012 8:24 AM > To: draft-li-behave-nat444-test@tools.ietf.org; 15301588336@189.cn; > 15306188213@189.cn; liuchunlin@jsptpd.com; Will Liu (Shucheng); > Zhangzongjian (Thomas) > Subject: comment on draft-li-behave-nat444-test-00, FTP active/passive > > Hi. > > It would be helpful in your FTP test results if you indicated if > passive > (PASV) or active mode was tested. > > -d > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From repenno@cisco.com Wed Jul 11 09:40:39 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4D521F85E5 for ; Wed, 11 Jul 2012 09:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id as-aSbL5SX+x for ; Wed, 11 Jul 2012 09:40:38 -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 BD0F121F85DB for ; Wed, 11 Jul 2012 09:40:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=repenno@cisco.com; l=2137; q=dns/txt; s=iport; t=1342024865; x=1343234465; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=TQ4HlOu+t/fgZEcvnmvQanTuOV7wtgPktsIhWlN71wk=; b=S4KHS2n/bAuJ1PJyemS6jA7jOqxdt8e9q2UUO3XhsSSOXnBpDz8mfrew Dg/tBsdDj2WGIRku7lbCNexHK66JyjWBgXLAX01smaSaApCIrQq/GR79I ElT0868ULrPqOQ4jl+jLxK6gUw53lHgVl9nGJr4FyjZcIwP90EQ9kraPC g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPqr/U+tJXG+/2dsb2JhbABFt2uBB4IgAQEBBAEBAQ8BFBM0CwwGARkEAQEfCS4LFAkIAgQBDQUih2sLnTCgHQSLQIVuA5U6jiCBZoJf X-IronPort-AV: E=Sophos;i="4.77,569,1336348800"; d="scan'208";a="100874939" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 11 Jul 2012 16:41:00 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q6BGf0cd024989 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Jul 2012 16:41:00 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.177]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0298.004; Wed, 11 Jul 2012 11:40:22 -0500 From: "Reinaldo Penno (repenno)" To: "Will Liu (Shucheng)" , "Zhangzongjian (Thomas)" , "Dan Wing (dwing)" , "draft-li-behave-nat444-test@tools.ietf.org" , "15301588336@189.cn" <15301588336@189.cn>, "15306188213@189.cn" <15306188213@189.cn>, "liuchunlin@jsptpd.com" Thread-Topic: Some comments on draft-li-behave-nat444-test-00 Thread-Index: AQHNX4PzQvoa1LGdNUeUjKld3jHzHA== Date: Wed, 11 Jul 2012 16:40:59 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.21.67.213] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19032.005 x-tm-as-result: No--35.152700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <00961D068F0FDC4ABFA2A20450259B06@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: [BEHAVE] Some comments on draft-li-behave-nat444-test-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 16:40:39 -0000 Hello, Some comments on your draft which I believe is interesting. Most of your tests are subscriber initiated connections which results in Internet (I) ->subscriber (S) traffic over TCP/UDP. We all know this works well with CGN. The interesting cases are I/S<->S for gratuitous connections. In that sense, some comments below. Is on-line gaming with consoles popular in China? PS3, XBOX, Nintendo? People do not seed torrents in China? That is very popular in other parts of the world.=20 I would like to understand how the CGN was configured. Were mappings APP enabled? EIM & EIF? Hairpinning enabled? This, of course is specially interesting on the I/S<->S scenarios. As far a VPN goes, the interesting ones from CGN perspective are IPsec (not over UDP) and PPTP. Thanks, - RP > >Have a nice day! >Will > >-----Original Message----- >From: Zhangzongjian (Thomas) >Sent: Wednesday, July 11, 2012 11:40 AM >To: Dan Wing; draft-li-behave-nat444-test@tools.ietf.org; >15301588336@189.cn; 15306188213@189.cn; liuchunlin@jsptpd.com; Will Liu >(Shucheng) >Cc: behave@ietf.org >Subject: RE: comment on draft-li-behave-nat444-test-00, FTP active/passive > >Dear Dan >In fact we tested the typical FTP active model as an illustration for the >FTP scenarios. In such an example, the FTP server is in public networks >and FTP client is in private network. Thanks for your comments. We will >add the detailed description in the next version. > >Thomas >Best regards > > >-----Original Message----- >From: Dan Wing [mailto:dwing@cisco.com] >Sent: Wednesday, July 11, 2012 8:24 AM >To: draft-li-behave-nat444-test@tools.ietf.org; 15301588336@189.cn; >15306188213@189.cn; liuchunlin@jsptpd.com; Will Liu (Shucheng); >Zhangzongjian (Thomas) >Subject: comment on draft-li-behave-nat444-test-00, FTP active/passive > >Hi. > >It would be helpful in your FTP test results if you indicated if passive >(PASV) or active mode was tested. > >-d > > >_______________________________________________ >Behave mailing list >Behave@ietf.org >https://www.ietf.org/mailman/listinfo/behave From hartmans@mit.edu Wed Jul 11 09:46:56 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 499F421F85F0; Wed, 11 Jul 2012 09:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.259 X-Spam-Level: X-Spam-Status: No, score=-103.259 tagged_above=-999 required=5 tests=[AWL=-0.994, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 zbjGmE3-IRhU; Wed, 11 Jul 2012 09:46:55 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id D064321F85EF; Wed, 11 Jul 2012 09:46:55 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 13BA5203BA; Wed, 11 Jul 2012 12:47:54 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 5BCEA41F0; Wed, 11 Jul 2012 12:47:16 -0400 (EDT) From: Sam Hartman To: Simon Perreault References: <4FF8A836.2090407@viagenie.ca> <4FFAF400.1030201@viagenie.ca> <1DF204BC-FAD6-4A0E-90B0-64760CC1ECF9@huawei.com> <4FFD8727.4020207@viagenie.ca> Date: Wed, 11 Jul 2012 12:47:16 -0400 In-Reply-To: <4FFD8727.4020207@viagenie.ca> (Simon Perreault's message of "Wed, 11 Jul 2012 10:01:11 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "behave@ietf.org" , "ietf@ietf.org" , "sunset4@ietf.org" , Tina TSOU Subject: Re: [BEHAVE] [sunset4] Last Call: (Common requirements for Carrier Grade NATs (CGNs)) to Best Current Practice X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jul 2012 16:46:56 -0000 Hi. I'd like to speak in favor of maintaining endpoint independent filtering as the default and maintaining requirement 11 D. I think requirement 11 D is important for avoiding some hard to analyze but potentially very dangerous security problems. If I can trick a NAT into replacing an existing mapping by causing resource exhaustion then I could probably attack that. Unfortunately such attacks tend to appear minor or hard to exploit until someone puts together what turns out to be a fairly reliable exploit against some equipment, then you have a real mess. I believe the stability of application argument argues for endpoint independent filtering. From internet-drafts@ietf.org Wed Jul 11 13:19:26 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1607C11E80EB; Wed, 11 Jul 2012 13:19:26 -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 nla4N423tGPm; Wed, 11 Jul 2012 13:19:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7198911E80EC; Wed, 11 Jul 2012 13:19: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: 4.30p3 Message-ID: <20120711201925.13168.12991.idtracker@ietfa.amsl.com> Date: Wed, 11 Jul 2012 13:19:25 -0700 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action: draft-ietf-behave-lsn-requirements-08.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, 11 Jul 2012 20:19: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 Avoida= nce Working Group of the IETF. Title : Common requirements for Carrier Grade NATs (CGNs) Author(s) : Simon Perreault Ikuhei Yamagata Shin Miyakawa Akira Nakagawa Hiroyuki Ashida Filename : draft-ietf-behave-lsn-requirements-08.txt Pages : 21 Date : 2012-07-11 Abstract: This document defines common requirements for Carrier-Grade NAT (CGN). It updates RFC 4787. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-behave-lsn-requirements There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-behave-lsn-requirements-08 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-behave-lsn-requirements-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From simon.perreault@viagenie.ca Wed Jul 11 13:24:14 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C20311E80DB; Wed, 11 Jul 2012 13:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLbjFodwbgyW; Wed, 11 Jul 2012 13:24:08 -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 CD5B911E80A2; Wed, 11 Jul 2012 13:24:08 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:8e70:5aff:fec5:72e4]) by jazz.viagenie.ca (Postfix) with ESMTPSA id D1114415D8; Wed, 11 Jul 2012 16:24:39 -0400 (EDT) Message-ID: <4FFDE107.50108@viagenie.ca> Date: Wed, 11 Jul 2012 16:24:39 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: The IESG References: <20120711201925.13168.12991.idtracker@ietfa.amsl.com> In-Reply-To: <20120711201925.13168.12991.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: behave@ietf.org Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-lsn-requirements-08.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, 11 Jul 2012 20:24:14 -0000 This new revision addresses the comments received during IETF last call. Here's the change log: o Made it super explicit that we're talking about an IPv4-only CGN logical *function*, not an IPv4-only CGN *scenario*. This changes and simplifies the definition of CGN a bit. o Did NOT change the intended status. Further guidance from IESG is necessary. o Fixed a huge typo in REQ-7. o Fixed bugs in REQ-5-B justification. o Added REQ-9 items A to D which constrain PCP server behavior. Simon On 07/11/2012 04:19 PM, 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 NATs (CGNs) > Author(s) : Simon Perreault > Ikuhei Yamagata > Shin Miyakawa > Akira Nakagawa > Hiroyuki Ashida > Filename : draft-ietf-behave-lsn-requirements-08.txt > Pages : 21 > Date : 2012-07-11 > > Abstract: > This document defines common requirements for Carrier-Grade NAT > (CGN). It updates RFC 4787. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-behave-lsn-requirements > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-behave-lsn-requirements-08 > > A diff from previous version is available at: > http://tools.ietf.org/rfcdiff?url2=draft-ietf-behave-lsn-requirements-08 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > 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 liushucheng@huawei.com Wed Jul 11 20:12:39 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9725D11E8100 for ; Wed, 11 Jul 2012 20:12:39 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mCN97Cc2SvJ8 for ; Wed, 11 Jul 2012 20:12:38 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8B60A11E80B8 for ; Wed, 11 Jul 2012 20:12:38 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHY33031; Wed, 11 Jul 2012 23:13:10 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 11 Jul 2012 20:10:42 -0700 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 11 Jul 2012 20:10:40 -0700 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.75]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.01.0323.003; Thu, 12 Jul 2012 11:10:29 +0800 From: "Will Liu (Shucheng)" To: Dan Wing , "Zhangzongjian (Thomas)" , "draft-li-behave-nat444-test@tools.ietf.org" , "15301588336@189.cn" <15301588336@189.cn>, "15306188213@189.cn" <15306188213@189.cn>, "liuchunlin@jsptpd.com" Thread-Topic: [BEHAVE] comment on draft-li-behave-nat444-test-00, FTP active/passive Thread-Index: AQHNX3b4h7W5X72vskm19eILVZahlZck7XXg Date: Thu, 12 Jul 2012 03:10:27 +0000 Message-ID: References: <085801cd5efb$8344aa50$89cdfef0$@com> <0B2F754289D27B449F7F1B95456B77544EDB63D7@szxeml524-mbs.china.huawei.com> <09b901cd5f76$f3ccfe50$db66faf0$@com> In-Reply-To: <09b901cd5f76$f3ccfe50$db66faf0$@com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.79.130] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "behave@ietf.org" Subject: Re: [BEHAVE] comment on draft-li-behave-nat444-test-00, FTP active/passive X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jul 2012 03:12:39 -0000 Thanks for sharing your statistics, which is very interesting and also help= ful for us. You are correct. As far as we know, both IE6 and ftp command in= DOS (in windows) are using the Active(PORT) mode as the default mode, whic= h are still widely used in China. However, as IE8/Firefox/chrome and Win7 s= pread in China in recent years, more and more FTPs are working under the pa= ssive mode. For your question about the number of active mode FTP, we afrai= d that we do not have the statistics for the number of active/passive mode. As I double checked our testing result, it was generated from the default D= OS (in windows) ftp command, under the PASSIVE mode. Just as you mentioned,= passive FTP does not need an FTP ALG. That's why I used the "typical" word= .=20 I hope my answer is helpful.=20 Cheers, Will -----Original Message----- From: Dan Wing [mailto:dwing@cisco.com]=20 Sent: Wednesday, July 11, 2012 11:08 PM To: Zhangzongjian (Thomas); draft-li-behave-nat444-test@tools.ietf.org; 153= 01588336@189.cn; 15306188213@189.cn; liuchunlin@jsptpd.com; Will Liu (Shuch= eng) Cc: behave@ietf.org Subject: RE: [BEHAVE] comment on draft-li-behave-nat444-test-00, FTP active= /passive > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Zhangzongjian (Thomas) > Sent: Tuesday, July 10, 2012 8:40 PM > To: Dan Wing; draft-li-behave-nat444-test@tools.ietf.org; > 15301588336@189.cn; 15306188213@189.cn; liuchunlin@jsptpd.com; Will Liu > (Shucheng) > Cc: behave@ietf.org > Subject: Re: [BEHAVE] comment on draft-li-behave-nat444-test-00, FTP > active/passive >=20 > Dear Dan > In fact we tested the typical FTP active model as an illustration for > the FTP scenarios. My statistics show that active FTP is not typical. Several years ago I obtained logs from ftp.cisco.com and 99% of our connections were passive-mode FTP. It was only one user, downloading several files, that wa= s using active-mode FTP, and had an IP address belonging to Boeing. All web browsers do passive-mode FTP by default or exclusively, including IE 7 and up, Safari, Firefox, Opera, and Chrome. Do you have statistics showing a high number of active mode FTP? Perhaps this is caused by IE 6, which I know is still used extensively in China, an= d defaults to active-mode FTP. It would be interesting to know how often active mode FTP is used considering it would also require FTP ALG support i= n existing WiFi access points (restaurants, hotels, and airports). > In such an example, the FTP server is in public > networks and FTP client is in private network. Thanks for your > comments. We will add the detailed description in the next version. Thanks, that would be helpful. As you know, passive FTP does not need an FTP ALG. -d > Thomas > Best regards >=20 >=20 > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Wednesday, July 11, 2012 8:24 AM > To: draft-li-behave-nat444-test@tools.ietf.org; 15301588336@189.cn; > 15306188213@189.cn; liuchunlin@jsptpd.com; Will Liu (Shucheng); > Zhangzongjian (Thomas) > Subject: comment on draft-li-behave-nat444-test-00, FTP active/passive >=20 > Hi. >=20 > It would be helpful in your FTP test results if you indicated if > passive > (PASV) or active mode was tested. >=20 > -d >=20 >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From zhangzhongjian@huawei.com Wed Jul 11 20:57:47 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7725E11E80ED; Wed, 11 Jul 2012 20:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2k45MQHLRtO; Wed, 11 Jul 2012 20:57:46 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 83B2A11E80A4; Wed, 11 Jul 2012 20:57:46 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHR38851; Wed, 11 Jul 2012 23:58:18 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 11 Jul 2012 20:55:23 -0700 Received: from SZXEML430-HUB.china.huawei.com (10.72.61.38) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 11 Jul 2012 20:55:22 -0700 Received: from SZXEML524-MBS.china.huawei.com ([169.254.5.229]) by szxeml430-hub.china.huawei.com ([10.72.61.38]) with mapi id 14.01.0323.003; Thu, 12 Jul 2012 11:55:13 +0800 From: "Zhangzongjian (Thomas)" To: "Reinaldo Penno (repenno)" , "Will Liu (Shucheng)" , "Dan Wing (dwing)" , "draft-li-behave-nat444-test@tools.ietf.org" , "15301588336@189.cn" <15301588336@189.cn>, "15306188213@189.cn" <15306188213@189.cn>, "liuchunlin@jsptpd.com" Thread-Topic: Some comments on draft-li-behave-nat444-test-00 Thread-Index: AQHNX4P7nT9/4eoqzk2YsKzuqVMXEpck8Ygg Date: Thu, 12 Jul 2012 03:55:12 +0000 Message-ID: <0B2F754289D27B449F7F1B95456B77544EDB6673@szxeml524-mbs.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.77.96] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "behave@ietf.org" , "sunset4@ietf.org" Subject: Re: [BEHAVE] Some comments on draft-li-behave-nat444-test-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 03:57:47 -0000 Dear Penno The answers are online below. Best regards thomas -----Original Message----- From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com]=20 Sent: Thursday, July 12, 2012 12:41 AM To: Will Liu (Shucheng); Zhangzongjian (Thomas); Dan Wing (dwing); draft-li= -behave-nat444-test@tools.ietf.org; 15301588336@189.cn; 15306188213@189.cn;= liuchunlin@jsptpd.com Cc: behave@ietf.org Subject: Some comments on draft-li-behave-nat444-test-00 Hello, Some comments on your draft which I believe is interesting. Most of your tests are subscriber initiated connections which results in Internet (I) ->subscriber (S) traffic over TCP/UDP. We all know this works well with CGN. The interesting cases are I/S<->S for gratuitous connections. In that sense, some comments below. Is on-line gaming with consoles popular in China? PS3, XBOX, Nintendo? Thomas: PS3, XBOX, Nintendo is seldom played in China. PS3, XBOX, Nintendo are not = published in China and there are no game servers for these three game in Ch= ina. People do not seed torrents in China? That is very popular in other parts of the world.=20 Thomas: Yes, People seed torrents, but rarely. =20 We mainly tested download in Bittorrent and eMule. I would like to understand how the CGN was configured. Were mappings APP enabled? EIM & EIF? Hairpinning enabled? This, of course is specially interesting on the I/S<->S scenarios. Thomas: Mappings are enabled by a service board in CGN device. CGN packets will be= sent to this board. I am not sure whether this answer can satisfy your qu= estion. The mapping is EIM without EIF. Which application CGN configuration are you interesting in? what configurat= ion do you want to know? I will try to provide more information for you, t= hough I not sure I can get configure from China Telecom. As far a VPN goes, the interesting ones from CGN perspective are IPsec (not over UDP) and PPTP. Thomas: In VPN fields, only iAccess is tested. IPsec and PPTP are not tested. Thanks, - RP > >Have a nice day! >Will > >-----Original Message----- >From: Zhangzongjian (Thomas) >Sent: Wednesday, July 11, 2012 11:40 AM >To: Dan Wing; draft-li-behave-nat444-test@tools.ietf.org; >15301588336@189.cn; 15306188213@189.cn; liuchunlin@jsptpd.com; Will Liu >(Shucheng) >Cc: behave@ietf.org >Subject: RE: comment on draft-li-behave-nat444-test-00, FTP active/passive > >Dear Dan >In fact we tested the typical FTP active model as an illustration for the >FTP scenarios. In such an example, the FTP server is in public networks >and FTP client is in private network. Thanks for your comments. We will >add the detailed description in the next version. > >Thomas >Best regards > > >-----Original Message----- >From: Dan Wing [mailto:dwing@cisco.com] >Sent: Wednesday, July 11, 2012 8:24 AM >To: draft-li-behave-nat444-test@tools.ietf.org; 15301588336@189.cn; >15306188213@189.cn; liuchunlin@jsptpd.com; Will Liu (Shucheng); >Zhangzongjian (Thomas) >Subject: comment on draft-li-behave-nat444-test-00, FTP active/passive > >Hi. > >It would be helpful in your FTP test results if you indicated if passive >(PASV) or active mode was tested. > >-d > > >_______________________________________________ >Behave mailing list >Behave@ietf.org >https://www.ietf.org/mailman/listinfo/behave From internet-drafts@ietf.org Mon Jul 16 08:33:19 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B273A21F865C; Mon, 16 Jul 2012 08:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 ZodA7Hr10rds; Mon, 16 Jul 2012 08:33:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 060F821F865D; Mon, 16 Jul 2012 08:33:19 -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: 4.30p3 Message-ID: <20120716153319.29743.27421.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2012 08:33:19 -0700 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action: draft-ietf-behave-nat-mib-02.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 15:33:20 -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 Avoida= nce Working Group of the IETF. Title : Additional Managed Objects for Network Address Translato= rs (NAT) Author(s) : Simon Perreault Tina Tsou Senthil Sivakumar Filename : draft-ietf-behave-nat-mib-02.txt Pages : 71 Date : 2012-07-16 Abstract: This memo defines a portion of the Management Information Base (MIB) for devices implementing Network Address Translator (NAT) function. This MIB module may be used for monitoring of a device capable of NAT function. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-behave-nat-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-behave-nat-mib-02 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-behave-nat-mib-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From simon.perreault@viagenie.ca Mon Jul 16 08:40:36 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B51F121F869C for ; Mon, 16 Jul 2012 08:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.43 X-Spam-Level: X-Spam-Status: No, score=-2.43 tagged_above=-999 required=5 tests=[AWL=0.170, 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 QYrTiFfJcsPj for ; Mon, 16 Jul 2012 08:40: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 B2A4721F869A for ; Mon, 16 Jul 2012 08:40:35 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:8e70:5aff:fec5:72e4]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 3B30B40099 for ; Mon, 16 Jul 2012 11:41:20 -0400 (EDT) Message-ID: <5004361F.6040509@viagenie.ca> Date: Mon, 16 Jul 2012 11:41:19 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: behave@ietf.org References: <20120716153319.29743.27421.idtracker@ietfa.amsl.com> In-Reply-To: <20120716153319.29743.27421.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-nat-mib-02.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 15:40:36 -0000 WG, Fairly heavy changes in this revision... (and I just noticed we forgot to update the change log appendix) Anyway, here's basically what we did: - The MIB has been merged with the one from RFC 4008. - The "NEW-" prefix was dropped. - All objects from RFC 4008 have been marked deprecated. - Our draft now should say "Obsoletes: 4008" (meant to do it but forgot, will be added in -03) - Added section 2.1 that explains in detail why 4008 objects are deprecated. - Removed all CGN-specific things and resubmitted them as draft-perreault-sunset4-cgn-mib-00. Feedback very much appreciated. And sorry for the two editing mistakes. Simon On 07/16/2012 11:33 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. > > Title : Additional Managed Objects for Network Address Translators (NAT) > Author(s) : Simon Perreault > Tina Tsou > Senthil Sivakumar > Filename : draft-ietf-behave-nat-mib-02.txt > Pages : 71 > Date : 2012-07-16 > > Abstract: > This memo defines a portion of the Management Information Base (MIB) > for devices implementing Network Address Translator (NAT) function. > This MIB module may be used for monitoring of a device capable of NAT > function. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-behave-nat-mib > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-behave-nat-mib-02 > > A diff from previous version is available at: > http://tools.ietf.org/rfcdiff?url2=draft-ietf-behave-nat-mib-02 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > 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 repenno@cisco.com Mon Jul 16 09:45:52 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE81511E809B for ; Mon, 16 Jul 2012 09:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJGBIWMFFpF7 for ; Mon, 16 Jul 2012 09:45:50 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7AD21F8671 for ; Mon, 16 Jul 2012 09:45:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1178; q=dns/txt; s=iport; t=1342457194; x=1343666794; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=OplNAK4j93wwnk0PzBz+x6PPTNAosjgsSoUqACUrujI=; b=KlsHiVh+1XHqaG8M4I/Aq8Twk5u0UTWS3eTqZP13EhpSw3mhSh4N9Y+r /JRiZfHkcxIQrDfqAX9GAx+GnFHSdavY7c2aHKBnt9b5hf7gIi9RjECag jkKWzICcMBfY3u7H7gc/C13PaiIYg1V6/I9oM60g7Y80gYe3AhNg2siY3 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABREBFCtJXG9/2dsb2JhbABFuUmBB4IgAQIEEgEnPRQBCDZCGwEGAwIEEwkZh2sLmwCBKJ9ukgcDlTuBEo0OgWaCXw X-IronPort-AV: E=Sophos;i="4.77,594,1336348800"; d="scan'208";a="99308861" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-9.cisco.com with ESMTP; 16 Jul 2012 16:46:34 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q6GGkXkQ014001 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 16 Jul 2012 16:46:33 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.177]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0298.004; Mon, 16 Jul 2012 11:46:33 -0500 From: "Reinaldo Penno (repenno)" To: "behave@ietf.org" Thread-Topic: New Version Notification for draft-penno-behave-rfc4787-5382-5508-bis-03.txt Thread-Index: AQHNY3KOGmcYT5rtSUu8iABIFwA/hg== Date: Mon, 16 Jul 2012 16:46:33 +0000 Message-ID: In-Reply-To: <20120716164126.18055.41367.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.21.146.105] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19042.006 x-tm-as-result: No--31.493700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <92B6C39F5BE3CA428A086029D96912AE@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [BEHAVE] FW: New Version Notification for draft-penno-behave-rfc4787-5382-5508-bis-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, 16 Jul 2012 16:45:52 -0000 On 7/16/12 9:41 AM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-penno-behave-rfc4787-5382-5508-bis-03.txt >has been successfully submitted by Reinaldo Penno and posted to the >IETF repository. > >Filename: draft-penno-behave-rfc4787-5382-5508-bis >Revision: 03 >Title: Network Address Translation (NAT) Behavioral Requirements Updates >Creation date: 2012-07-15 >WG ID: Individual Submission >Number of pages: 10 >URL: =20 >http://www.ietf.org/internet-drafts/draft-penno-behave-rfc4787-5382-5508-b >is-03.txt >Status: =20 >http://datatracker.ietf.org/doc/draft-penno-behave-rfc4787-5382-5508-bis >Htmlized: =20 >http://tools.ietf.org/html/draft-penno-behave-rfc4787-5382-5508-bis-03 >Diff: =20 >http://tools.ietf.org/rfcdiff?url2=3Ddraft-penno-behave-rfc4787-5382-5508-= bi >s-03 > >Abstract: > This document clarifies and updates several requirements of RFC4787, > RFC5382 and RFC5508 based on operational and development experience. > The focus of this document is NAPT44. > > > =20 > =20 > > >The IETF Secretariat From dwing@cisco.com Mon Jul 16 10:54:54 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBD3711E8283 for ; Mon, 16 Jul 2012 10:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.487 X-Spam-Level: X-Spam-Status: No, score=-110.487 tagged_above=-999 required=5 tests=[AWL=0.112, 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 JrBxcoij1uLy for ; Mon, 16 Jul 2012 10:54:53 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id D37B411E8282 for ; Mon, 16 Jul 2012 10:54:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=991; q=dns/txt; s=iport; t=1342461338; x=1343670938; h=from:to:subject:date:message-id:mime-version: content-transfer-encoding; bh=Xy7YsE9bLXnd6lPzwUsNeEv1OEpsEJvzIE7nPp0vFYw=; b=HzYdzcE9djnknUfXzkaGVyaAUGURxs7Dhctiv5UCAzhGUl+Jb5TmBWEV olfR/4lFpvn/KdOcbgKoX2OJkCpHiFFd/zCJX3h05Beqnwot5m8j3jroB mJveoO0PH+4AbF94t5a7tmg0JiU+joa9Y6rhFpToZrMkPyxS5u+i8SOcr Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAGlVBFCrRDoH/2dsb2JhbABFqg6PPYEHgicICgEXEEwFGFAjHAEEHheHagybA4Eon3iOa4McA4hLhQWIfY0OgWaCfw X-IronPort-AV: E=Sophos;i="4.77,595,1336348800"; d="scan'208";a="49510869" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 16 Jul 2012 17:55:38 +0000 Received: from dwingWS (sjc-vpn2-417.cisco.com [10.21.113.161]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q6GHtbKJ028708 for ; Mon, 16 Jul 2012 17:55:37 GMT From: "Dan Wing" To: Date: Mon, 16 Jul 2012 10:55:37 -0700 Message-ID: <035801cd637c$34df33f0$9e9d9bd0$@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: Ac1jfDSEsfkpVZMvSuucIiFo9SIW+w== Content-Language: en-us Subject: [BEHAVE] four data models: SYSLOG, IPFIX, SNMP, RADIUS X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 17:54:54 -0000 As an individual, I have been worried about the possibility of disparate data models for NATs. We currently have four ways to report information about a NAT or other address-sharing device, SYSLOG, http://tools.ietf.org/html/draft-zhou-behave-syslog-nat-logging-00 IPFIX, http://tools.ietf.org/html/draft-sivakumar-behave-nat-logging-05 SNMP, http://tools.ietf.org/html/draft-perreault-sunset4-cgn-mib RADIUS, http://tools.ietf.org/html/draft-cheng-behave-cgn-cfg-radius-ext-03#section- 4.2 My concern is that operators may find it necessary to deploy all four protocols (IPFIX, SYSLOG, SNMP, and RADIUS) to get their needed logging and. This seems undesirable. Imagine, for example, that only one of those protocols supported pseudo-random port assignment but only one other protocol provided alarms for when a subscriber consumed all their ports (and thus might open a support case with the operator that "the Internet is down"). Are my concerns misplaced? -d From hannes.tschofenig@gmx.net Mon Jul 16 11:03:59 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB4EC21F86B3 for ; Mon, 16 Jul 2012 11:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.627 X-Spam-Level: X-Spam-Status: No, score=-102.627 tagged_above=-999 required=5 tests=[AWL=-0.028, 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 tZ45EeYQuQ0Y for ; Mon, 16 Jul 2012 11:03:59 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id E167021F8680 for ; Mon, 16 Jul 2012 11:03:58 -0700 (PDT) Received: (qmail invoked by alias); 16 Jul 2012 18:04:24 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.102]) [88.115.216.191] by mail.gmx.net (mp019) with SMTP; 16 Jul 2012 20:04:24 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX199v+oHp4F9N6vawZzFufqO8Qd480EMt6r2KdvjM3 NlfFF4vaudF30c Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <035801cd637c$34df33f0$9e9d9bd0$@com> Date: Mon, 16 Jul 2012 21:04:22 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <0971ABA3-9A9A-46FB-BE12-7A1F27F255D7@gmx.net> References: <035801cd637c$34df33f0$9e9d9bd0$@com> To: "Dan Wing" X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: behave@ietf.org Subject: Re: [BEHAVE] four data models: SYSLOG, IPFIX, SNMP, RADIUS X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 18:04:00 -0000 You of course forgot Diameter:=20 http://tools.ietf.org/html/draft-ietf-dime-nat-control-17 Operators deploy different protocols for different purposes.=20 The world would be great if everyone could agree to use only one = protocol, like in the voice over IP world (for example)... On Jul 16, 2012, at 8:55 PM, Dan Wing wrote: > As an individual, I have been worried about the possibility of = disparate > data models for NATs. We currently have four ways to report = information > about a NAT or other address-sharing device, >=20 > SYSLOG, = http://tools.ietf.org/html/draft-zhou-behave-syslog-nat-logging-00 > IPFIX, = http://tools.ietf.org/html/draft-sivakumar-behave-nat-logging-05=20 > SNMP, http://tools.ietf.org/html/draft-perreault-sunset4-cgn-mib > RADIUS, > = http://tools.ietf.org/html/draft-cheng-behave-cgn-cfg-radius-ext-03#sectio= n- > 4.2 >=20 > My concern is that operators may find it necessary to deploy all four > protocols (IPFIX, SYSLOG, SNMP, and RADIUS) to get their needed = logging and. > This seems undesirable. Imagine, for example, that only one of those > protocols supported pseudo-random port assignment but only one other > protocol provided alarms for when a subscriber consumed all their = ports (and > thus might open a support case with the operator that "the Internet is > down"). >=20 > Are my concerns misplaced? >=20 > -d >=20 >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From dwing@cisco.com Mon Jul 16 11:10:55 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEBCD11E80EA for ; Mon, 16 Jul 2012 11:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.49 X-Spam-Level: X-Spam-Status: No, score=-110.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 6c0Sy8SF2tqf for ; Mon, 16 Jul 2012 11:10:55 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 648AB11E808C for ; Mon, 16 Jul 2012 11:10:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2006; q=dns/txt; s=iport; t=1342462300; x=1343671900; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=y+rqOFL6Z9WXuUPO59qRA59XmQyiTXxTmry7qrmUXks=; b=JpzbchVX2Zy4/qcIf6ij3C4x5S85opV3Z5DA+hBdbyq2v/ae6l31TndQ EbJE3NjZt0dxCemJCSJlrPjnSGwuPuVCfCqYu04mj08qoFUpL7bFTMIvz Z79MYO00lMAu7KEn/wYcr5OLuy+xoZhKM9uuupXOcEXbkpRIe9yg3MwEe w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFAJdYBFCrRDoJ/2dsb2JhbABFqhCPPYEHgiABAQEDAQEBAQUKARcQNAsFBwEDAgkPAgQBAQEnBxkOFQoJCAEBBBMLF4dcAwYFDJwhn3iKWmaGRwOIS4UFiH2NDoFmgn8 X-IronPort-AV: E=Sophos;i="4.77,595,1336348800"; d="scan'208";a="49512235" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 16 Jul 2012 18:11:40 +0000 Received: from dwingWS (sjc-vpn2-417.cisco.com [10.21.113.161]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q6GIBdGY020075; Mon, 16 Jul 2012 18:11:40 GMT From: "Dan Wing" To: "'Hannes Tschofenig'" References: <035801cd637c$34df33f0$9e9d9bd0$@com> <0971ABA3-9A9A-46FB-BE12-7A1F27F255D7@gmx.net> In-Reply-To: <0971ABA3-9A9A-46FB-BE12-7A1F27F255D7@gmx.net> Date: Mon, 16 Jul 2012 11:11:39 -0700 Message-ID: <038601cd637e$7298d460$57ca7d20$@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: Ac1jfXw8ISDNwgUuQGy14DlcaWXuIgAAOFjQ Content-Language: en-us Cc: behave@ietf.org Subject: Re: [BEHAVE] four data models: SYSLOG, IPFIX, SNMP, RADIUS X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 18:10:56 -0000 > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] > Sent: Monday, July 16, 2012 11:04 AM > To: Dan Wing > Cc: Hannes Tschofenig; behave@ietf.org > Subject: Re: [BEHAVE] four data models: SYSLOG, IPFIX, SNMP, RADIUS > > You of course forgot Diameter: > http://tools.ietf.org/html/draft-ietf-dime-nat-control-17 > > Operators deploy different protocols for different purposes. That was not my question. My question was forcing operators to deploy multiple protocols to meet their purposes. -d > The world would be great if everyone could agree to use only one > protocol, like in the voice over IP world (for example)... > > On Jul 16, 2012, at 8:55 PM, Dan Wing wrote: > > > As an individual, I have been worried about the possibility of > disparate > > data models for NATs. We currently have four ways to report > information > > about a NAT or other address-sharing device, > > > > SYSLOG, http://tools.ietf.org/html/draft-zhou-behave-syslog-nat- > logging-00 > > IPFIX, http://tools.ietf.org/html/draft-sivakumar-behave-nat-logging- > 05 > > SNMP, http://tools.ietf.org/html/draft-perreault-sunset4-cgn-mib > > RADIUS, > > http://tools.ietf.org/html/draft-cheng-behave-cgn-cfg-radius-ext- > 03#section- > > 4.2 > > > > My concern is that operators may find it necessary to deploy all four > > protocols (IPFIX, SYSLOG, SNMP, and RADIUS) to get their needed > logging and. > > This seems undesirable. Imagine, for example, that only one of those > > protocols supported pseudo-random port assignment but only one other > > protocol provided alarms for when a subscriber consumed all their > ports (and > > thus might open a support case with the operator that "the Internet > is > > down"). > > > > Are my concerns misplaced? > > > > -d > > > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave From sarikaya2012@gmail.com Mon Jul 16 15:18:57 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 750FF11E8163 for ; Mon, 16 Jul 2012 15:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.538 X-Spam-Level: X-Spam-Status: No, score=-3.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kvm444a-HVyj for ; Mon, 16 Jul 2012 15:18:57 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id DE3B411E813D for ; Mon, 16 Jul 2012 15:18:56 -0700 (PDT) Received: by yenq13 with SMTP id q13so6096850yen.31 for ; Mon, 16 Jul 2012 15:19:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=tRa4WiNG1M55q2oL90LTdl4v/KAOs4I6aF/wuaHJwDI=; b=dzCnibNPaIvDdtrUXNvTF7efTWDWjmrlRB3qZUZ2vVF0+nF3H7mySLkIOna2ANOThG 6rlmIU6yDzTi+B0sGB00HB9ZdDSnj2NuI+1fMeQSef7KZ7NpWRXf9csMX1lBJnjiBaU/ n7G6hlQP9Ne+xWNmG0kp8rG2uWq5WsQA82AzB9y+GfNVHDYWIuKb/ap4NmKEhQpThV1r fnfgIoSZTAQea0RAkif9+442QNs2KdEyMuYaDKSv3rZWplVSnlvNW+ljMM6HY13i5FB6 IfuMCSLnwWRM2quyGMU1F1mAtwC6CxjCGO+Gp7BRogOmiywP7Vp5rswxZ+c6lGwfSuAG N47Q== MIME-Version: 1.0 Received: by 10.50.195.234 with SMTP id ih10mr92766igc.0.1342477182044; Mon, 16 Jul 2012 15:19:42 -0700 (PDT) Received: by 10.231.207.167 with HTTP; Mon, 16 Jul 2012 15:19:41 -0700 (PDT) In-Reply-To: <20120716190808.8365.73841.idtracker@ietfa.amsl.com> References: <20120716190808.8365.73841.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2012 17:19:41 -0500 Message-ID: From: Behcet Sarikaya To: behave@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [BEHAVE] New Version Notification for draft-sarikaya-behave-mcast4nat64-06.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 22:18:57 -0000 A new version of I-D, draft-sarikaya-behave-mcast4nat64-06.txt has been successfully submitted by Behcet Sarikaya and posted to the IETF repository. Filename: draft-sarikaya-behave-mcast4nat64 Revision: 06 Title: Multicast Support for NAT64 Creation date: 2012-07-16 WG ID: Individual Submission Number of pages: 11 URL: http://www.ietf.org/internet-drafts/draft-sarikaya-behave-mcast4nat64-06.txt Status: http://datatracker.ietf.org/doc/draft-sarikaya-behave-mcast4nat64 Htmlized: http://tools.ietf.org/html/draft-sarikaya-behave-mcast4nat64-06 Diff: http://tools.ietf.org/rfcdiff?url2=draft-sarikaya-behave-mcast4nat64-06 Abstract: This memo specifies modifications required to NAT64 so that IPv6 only hosts can receive multicast data from IPv4 only servers. The protocol is based on translating IPv4 multicast data before delivering it to the host in IPv6. The protocol also allows IPv6 only host to join IPv4 any source/ source specific multicast group in IPv6 using Multicast Listener Discovery protocol. The IETF Secretariat From achatz@forthnetgroup.gr Mon Jul 16 15:19:15 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2573E11E82C6 for ; Mon, 16 Jul 2012 15:19:15 -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 xbud8CEBcYQc for ; Mon, 16 Jul 2012 15:19:14 -0700 (PDT) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.107]) by ietfa.amsl.com (Postfix) with ESMTP id EAC7911E826C for ; Mon, 16 Jul 2012 15:19:13 -0700 (PDT) Received: from mx-av-03.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-06.forthnet.gr (8.14.4/8.14.4) with ESMTP id q6GMJu4d007382; Tue, 17 Jul 2012 01:19:56 +0300 Received: from MX-IN-05.forthnet.gr (mx-in-05.forthnet.gr [193.92.150.30]) by mx-av-03.forthnet.gr (8.14.3/8.14.3) with ESMTP id q6GMJubH022220; Tue, 17 Jul 2012 01:19:56 +0300 Received: from [192.168.1.2] (46.246.204.91.dsl.dyn.forthnet.gr [46.246.204.91]) (authenticated bits=0) by MX-IN-05.forthnet.gr (8.14.4/8.14.4) with ESMTP id q6GMJtv6000412; Tue, 17 Jul 2012 01:19:56 +0300 Authentication-Results: MX-IN-05.forthnet.gr smtp.mail=achatz@forthnetgroup.gr; auth=pass (PLAIN) Message-ID: <5004938A.5050306@forthnetgroup.gr> Date: Tue, 17 Jul 2012 01:19:54 +0300 From: Tassos Chatzithomaoglou User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120615 Firefox/13.0.1 SeaMonkey/2.10.1 MIME-Version: 1.0 To: Dan Wing References: <035801cd637c$34df33f0$9e9d9bd0$@com> In-Reply-To: <035801cd637c$34df33f0$9e9d9bd0$@com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: behave@ietf.org Subject: Re: [BEHAVE] four data models: SYSLOG, IPFIX, SNMP, RADIUS X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 22:19:15 -0000 Imho, every protocol is destined to cover specific needs. For auditing reasons (which is my primary concern curtently) i would prefer to use RADIUS (or DIAMETER or anything AAA related), as long as the frequency of acct records remains within limits. Passing information to subscriber sessions could also be done through RADIUS push. SYSLOG is good for fast one way communication and maybe it could be used for alerting. SNMP (notifications) could also be used for alerting, but its usage for on-demand or historical detailed statistics gatherings should be preferred. IPFIX could be used for near realtime logging and of course for statistics. Generally i agree with your concerns, but instead of "choosing" only one protocol, i would prefer to have the scope of each protocol clearly/strictly defined, so depending on my needs i knew what to deploy. For me, it would be an ugly joke if i had to deploy SNMP or IPFIX in order to have the historical correlation of username & IP-related stuff. -- Tassos Dan Wing wrote on 16/7/2012 20:55: > As an individual, I have been worried about the possibility of disparate > data models for NATs. We currently have four ways to report information > about a NAT or other address-sharing device, > > SYSLOG, http://tools.ietf.org/html/draft-zhou-behave-syslog-nat-logging-00 > IPFIX, http://tools.ietf.org/html/draft-sivakumar-behave-nat-logging-05 > SNMP, http://tools.ietf.org/html/draft-perreault-sunset4-cgn-mib > RADIUS, > http://tools.ietf.org/html/draft-cheng-behave-cgn-cfg-radius-ext-03#section- > 4.2 > > My concern is that operators may find it necessary to deploy all four > protocols (IPFIX, SYSLOG, SNMP, and RADIUS) to get their needed logging and. > This seems undesirable. Imagine, for example, that only one of those > protocols supported pseudo-random port assignment but only one other > protocol provided alarms for when a subscriber consumed all their ports (and > thus might open a support case with the operator that "the Internet is > down"). > > Are my concerns misplaced? > > -d > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From repenno@cisco.com Mon Jul 16 15:41:24 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9796111E8340 for ; Mon, 16 Jul 2012 15:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OKFdOst+V7Q for ; Mon, 16 Jul 2012 15:41:23 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id B949A11E833D for ; Mon, 16 Jul 2012 15:41:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=repenno@cisco.com; l=3111; q=dns/txt; s=iport; t=1342478529; x=1343688129; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=ddVk3RiJdLmerO750aN+T2rqoSm72o90vU/iw4TTXDU=; b=WkCrKqgEnDl+/hQm/icGaSkJvpd+uGOL/TXCLdNcUIS6FC6HlAX+Xdlg Lw5QQPfA7CgaD/bgojP1PxNmpU08V1G3VpfsMHcdKI8/o0/QXh5mMbH48 2TXFeBs5plsb3Y68CdIIgxTDV2O2MT6YYgpu6jjwl/Yln57tZSxcW/331 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EADeXBFCtJV2d/2dsb2JhbABFuVGBB4IiAQQBAQEPASc0CxIBCA4oNwslAQEEAQ0FIodrC5wboB6LQIZHA5U7gRKNDoFmgl8 X-IronPort-AV: E=Sophos;i="4.77,597,1336348800"; d="scan'208";a="102404408" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 16 Jul 2012 22:42:09 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q6GMg97e006759 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 16 Jul 2012 22:42:09 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.177]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0298.004; Mon, 16 Jul 2012 17:42:07 -0500 From: "Reinaldo Penno (repenno)" To: Tassos Chatzithomaoglou , "Dan Wing (dwing)" Thread-Topic: [BEHAVE] four data models: SYSLOG, IPFIX, SNMP, RADIUS Thread-Index: Ac1jfDSEsfkpVZMvSuucIiFo9SIW+wATtQ8A//+Q2YA= Date: Mon, 16 Jul 2012 22:42:07 +0000 Message-ID: In-Reply-To: <5004938A.5050306@forthnetgroup.gr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.21.68.77] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19042.004 x-tm-as-result: No--44.033400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] four data models: SYSLOG, IPFIX, SNMP, RADIUS X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 22:41:24 -0000 I see the question a bit differently. I believe we should provide some level of standardization across these protocols. For example, binding type representation, port ranges, mapping count, etc should be represented by the same data model in all protocols. We proposed that in Taipei but at that time maybe the problem wasn't ripe. Going on step further, in case of NAT logging we should agree on basic information set irrespective if somebody would use Radius, IPFix or any other protocol. Thanks, Reinaldo =20 On 7/16/12 3:19 PM, "Tassos Chatzithomaoglou" wrote: >Imho, every protocol is destined to cover specific needs. > >For auditing reasons (which is my primary concern curtently) i would >prefer to use RADIUS >(or DIAMETER or anything AAA related), as long as the frequency of acct >records remains=20 >within limits. Passing information to subscriber sessions could also be >done through=20 >RADIUS push. >SYSLOG is good for fast one way communication and maybe it could be used >for alerting. >SNMP (notifications) could also be used for alerting, but its usage for >on-demand or=20 >historical detailed statistics gatherings should be preferred. >IPFIX could be used for near realtime logging and of course for >statistics. > >Generally i agree with your concerns, but instead of "choosing" only one >protocol, i would=20 >prefer to have the scope of each protocol clearly/strictly defined, so >depending on my=20 >needs i knew what to deploy. >For me, it would be an ugly joke if i had to deploy SNMP or IPFIX in >order to have the=20 >historical correlation of username & IP-related stuff. > >-- >Tassos > >Dan Wing wrote on 16/7/2012 20:55: >> As an individual, I have been worried about the possibility of disparate >> data models for NATs. We currently have four ways to report information >> about a NAT or other address-sharing device, >> >> SYSLOG,=20 >>http://tools.ietf.org/html/draft-zhou-behave-syslog-nat-logging-00 >> IPFIX, http://tools.ietf.org/html/draft-sivakumar-behave-nat-logging-05 >> SNMP, http://tools.ietf.org/html/draft-perreault-sunset4-cgn-mib >> RADIUS, >>=20 >>http://tools.ietf.org/html/draft-cheng-behave-cgn-cfg-radius-ext-03#secti >>on- >> 4.2 >> >> My concern is that operators may find it necessary to deploy all four >> protocols (IPFIX, SYSLOG, SNMP, and RADIUS) to get their needed logging >>and. >> This seems undesirable. Imagine, for example, that only one of those >> protocols supported pseudo-random port assignment but only one other >> protocol provided alarms for when a subscriber consumed all their ports >>(and >> thus might open a support case with the operator that "the Internet is >> down"). >> >> Are my concerns misplaced? >> >> -d >> >> >> _______________________________________________ >> 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 ietfdbh@comcast.net Mon Jul 16 16:27:04 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75DAE11E8275 for ; Mon, 16 Jul 2012 16:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8JSH87S2qiD for ; Mon, 16 Jul 2012 16:27:02 -0700 (PDT) Received: from qmta10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1E66B11E8162 for ; Mon, 16 Jul 2012 16:27:02 -0700 (PDT) Received: from omta12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by qmta10.emeryville.ca.mail.comcast.net with comcast id bBKV1j0020x6nqcAABTofZ; Mon, 16 Jul 2012 23:27:48 +0000 Received: from [192.168.6.52] ([64.134.178.150]) by omta12.emeryville.ca.mail.comcast.net with comcast id bBTQ1j01x3F50cG8YBTWsv; Mon, 16 Jul 2012 23:27:45 +0000 User-Agent: Microsoft-MacOutlook/14.2.2.120421 Date: Mon, 16 Jul 2012 19:27:22 -0400 From: David Harrington To: Tassos Chatzithomaoglou , Dan Wing Message-ID: Thread-Topic: [BEHAVE] four data models: SYSLOG, IPFIX, SNMP, RADIUS In-Reply-To: <5004938A.5050306@forthnetgroup.gr> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: behave@ietf.org Subject: Re: [BEHAVE] four data models: SYSLOG, IPFIX, SNMP, RADIUS X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 23:27:04 -0000 Hi, Here is the history of IETF network management protocol standards, as far as I have been able to determine. Around 1988, the IETF decided (following IAB recommendations found in RFC1052) to standardize SNMP as a stepping stone toward CMIP (and CMOT). The SMI data modeling language and the MIB database was designed to work with either SNMP or CMIP. Around 1992, the effort to move toward CMIP/CMOT was assessed and considered not worthwhile, and SNMP became "THE" IETF standard protocol for NM, for use with the SMI and the MIB standards. For multiple years, the argument that we should have only one standard for NM held sway and all OPS+Mgmt support meant write an SMI MIB and use SNMP to access the data. Around 1994, however, operators became much more vocal about the poor fit between SNMP and some of the tasks they needed to perform. SNMP works well for retrieving small amounts of data using ASN.1-formatted VarBinds, or getting asynchronous notifications. But for other purposes, other protocols were being used that better fit the needs of operators. So the IETF started standardizing additional protocols requested by the operator community (communities). And the IETF strategy changed to "build a toolkit of standardized protocols for managing networks". The IRTF (NMRG) produced a document describing the difference between an information model and data models. RADIUS (and later Diameter) were standardized for centralized authentication, authorization, and usage accounting. Flow accounting protocols like RTFM, Netflow, LFAP and CRANE were merged into an IETF standard that became IPFIX. Syslog was in wide use by operators, but it needed security features which demanded standardization of the protocol. The IETF produced RFC5424+. SNMP was not good at full-device config, so netconf was developed. RFC5706 was written to try to provide some guidance about considering operations and management in a multi-protocol, multi-data-model environment. And WGs such as netconf and opsawg started producing specifications about how to correlate and translate information between protocols and between data models. ISMS WG developed RADIUS support for use with SNMPv3. Netconf developed support for carrying syslog in netconf messages. Correlations/Translations were provided for syslog-to-snmp and snmp-to-syslog. Work has been done to correlate XML and YANG data modeling. Netconf/netmod is working on translating key mibs models into yang. And so on ... So, yes, operators may need to develop support for multiple protocols, and corresponding data models, for different purposes. It is what they have requested. Ideally, the IETF will try to standardize their ***information*** models, so different data models for different protocols can be correlated easily. Opsawg published a survey of IETF NM protocols and data models to help make this easier. WGs like behave and sunset4 and opsawg (and directorates such as MIB and YANG and AAA Doctors) will be key to driving some consistency across efforts. Regarding NAT logging, I think we need to make a distinction between device-event logging, auditing, and usage accounting. RFC2975 did an analysis of these things and appropriate protocols. But RFC2975 is pretty old now, and things have changed a lot since 2000. -- David Harrington Internet Engineering Task Force (IETF) Ietfdbh@comcast.net +1-603-828-1401 On 7/16/12 6:19 PM, "Tassos Chatzithomaoglou" wrote: >Imho, every protocol is destined to cover specific needs. > >For auditing reasons (which is my primary concern curtently) i would >prefer to use RADIUS >(or DIAMETER or anything AAA related), as long as the frequency of acct >records remains >within limits. Passing information to subscriber sessions could also be >done through >RADIUS push. >SYSLOG is good for fast one way communication and maybe it could be used >for alerting. >SNMP (notifications) could also be used for alerting, but its usage for >on-demand or >historical detailed statistics gatherings should be preferred. >IPFIX could be used for near realtime logging and of course for >statistics. > >Generally i agree with your concerns, but instead of "choosing" only one >protocol, i would >prefer to have the scope of each protocol clearly/strictly defined, so >depending on my >needs i knew what to deploy. >For me, it would be an ugly joke if i had to deploy SNMP or IPFIX in >order to have the >historical correlation of username & IP-related stuff. > >-- >Tassos > >Dan Wing wrote on 16/7/2012 20:55: >> As an individual, I have been worried about the possibility of disparate >> data models for NATs. We currently have four ways to report information >> about a NAT or other address-sharing device, >> >> SYSLOG, >>http://tools.ietf.org/html/draft-zhou-behave-syslog-nat-logging-00 >> IPFIX, http://tools.ietf.org/html/draft-sivakumar-behave-nat-logging-05 >> SNMP, http://tools.ietf.org/html/draft-perreault-sunset4-cgn-mib >> RADIUS, >> >>http://tools.ietf.org/html/draft-cheng-behave-cgn-cfg-radius-ext-03#secti >>on- >> 4.2 >> >> My concern is that operators may find it necessary to deploy all four >> protocols (IPFIX, SYSLOG, SNMP, and RADIUS) to get their needed logging >>and. >> This seems undesirable. Imagine, for example, that only one of those >> protocols supported pseudo-random port assignment but only one other >> protocol provided alarms for when a subscriber consumed all their ports >>(and >> thus might open a support case with the operator that "the Internet is >> down"). >> >> Are my concerns misplaced? >> >> -d >> >> >> _______________________________________________ >> 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 cathy.zhou@huawei.com Mon Jul 16 18:53:00 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7853E11E809F for ; Mon, 16 Jul 2012 18:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.446 X-Spam-Level: X-Spam-Status: No, score=-6.446 tagged_above=-999 required=5 tests=[AWL=0.153, 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 Aq0DMSXc2Rsi for ; Mon, 16 Jul 2012 18:53:00 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD5811E809A for ; Mon, 16 Jul 2012 18:53:00 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIB80177; Mon, 16 Jul 2012 21:53:46 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 16 Jul 2012 18:51:50 -0700 Received: from SZXEML433-HUB.china.huawei.com (10.72.61.61) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 16 Jul 2012 18:51:52 -0700 Received: from SZXEML527-MBX.china.huawei.com ([169.254.3.194]) by szxeml433-hub.china.huawei.com ([10.72.61.61]) with mapi id 14.01.0323.003; Tue, 17 Jul 2012 09:51:48 +0800 From: "Zhouqian (Cathy)" To: "Behave@ietf.org" Thread-Topic: Support syslog nat logging in Behave? Thread-Index: Ac1jvroZ6hquIfuBS7yjhi9jCdN3zQ== Date: Tue, 17 Jul 2012 01:51:47 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.77.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [BEHAVE] Support syslog nat logging in Behave? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 01:53:00 -0000 Dear all, We have submitted a document to Behave WG to propose the syslog support on = nat logging.=20 The document link is below: http://www.ietf.org/internet-drafts/draft-zhou-behave-syslog-nat-logging-00= .txt I am sending this email for your comments and to ask the Working Group's op= inion whether this work should be included in the Behave charter.=20 Best Regards, Cathy From ietfdbh@comcast.net Mon Jul 16 19:12:42 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFA1B11E8089 for ; Mon, 16 Jul 2012 19:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 Hd1PwhDpYEto for ; Mon, 16 Jul 2012 19:12:41 -0700 (PDT) Received: from qmta14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [76.96.27.212]) by ietfa.amsl.com (Postfix) with ESMTP id 43CAE11E8087 for ; Mon, 16 Jul 2012 19:12:41 -0700 (PDT) Received: from omta05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by qmta14.emeryville.ca.mail.comcast.net with comcast id bEDE1j0030vp7WLAEEDTaE; Tue, 17 Jul 2012 02:13:27 +0000 Received: from [192.168.6.52] ([64.134.178.150]) by omta05.emeryville.ca.mail.comcast.net with comcast id bED81j00M3F50cG8REDBS7; Tue, 17 Jul 2012 02:13:25 +0000 User-Agent: Microsoft-MacOutlook/14.2.2.120421 Date: Mon, 16 Jul 2012 22:13:05 -0400 From: David Harrington To: "Reinaldo Penno (repenno)" , Tassos Chatzithomaoglou , "Dan Wing (dwing)" Message-ID: Thread-Topic: [BEHAVE] four data models: SYSLOG, IPFIX, SNMP, RADIUS In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] four data models: SYSLOG, IPFIX, SNMP, RADIUS X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 02:12:42 -0000 Hi, I agree we should try to standardize a limited **information model** (see rfc3444) for nat logging. Then we should standardize one or more protocol-specific data models. I do not think we should produce every variant of data model just because we can; there should be solid justification for each standard model. I would like to see what proprietary solutions are already being used widely, and would benefit from standardization. -- David Harrington Internet Engineering Task Force (IETF) Ietfdbh@comcast.net +1-603-828-1401 On 7/16/12 6:42 PM, "Reinaldo Penno (repenno)" wrote: >I see the question a bit differently. > >I believe we should provide some level of standardization across these >protocols. For example, binding type representation, port ranges, mapping >count, etc should be represented by the same data model in all protocols. >We proposed that in Taipei but at that time maybe the problem wasn't ripe. > >Going on step further, in case of NAT logging we should agree on basic >information set irrespective if somebody would use Radius, IPFix or any >other protocol. > >Thanks, > >Reinaldo > >On 7/16/12 3:19 PM, "Tassos Chatzithomaoglou" >wrote: > >>Imho, every protocol is destined to cover specific needs. >> >>For auditing reasons (which is my primary concern curtently) i would >>prefer to use RADIUS >>(or DIAMETER or anything AAA related), as long as the frequency of acct >>records remains >>within limits. Passing information to subscriber sessions could also be >>done through >>RADIUS push. >>SYSLOG is good for fast one way communication and maybe it could be used >>for alerting. >>SNMP (notifications) could also be used for alerting, but its usage for >>on-demand or >>historical detailed statistics gatherings should be preferred. >>IPFIX could be used for near realtime logging and of course for >>statistics. >> >>Generally i agree with your concerns, but instead of "choosing" only one >>protocol, i would >>prefer to have the scope of each protocol clearly/strictly defined, so >>depending on my >>needs i knew what to deploy. >>For me, it would be an ugly joke if i had to deploy SNMP or IPFIX in >>order to have the >>historical correlation of username & IP-related stuff. >> >>-- >>Tassos >> >>Dan Wing wrote on 16/7/2012 20:55: >>> As an individual, I have been worried about the possibility of >>>disparate >>> data models for NATs. We currently have four ways to report >>>information >>> about a NAT or other address-sharing device, >>> >>> SYSLOG, >>>http://tools.ietf.org/html/draft-zhou-behave-syslog-nat-logging-00 >>> IPFIX, http://tools.ietf.org/html/draft-sivakumar-behave-nat-logging-05 >>> SNMP, http://tools.ietf.org/html/draft-perreault-sunset4-cgn-mib >>> RADIUS, >>> >>>http://tools.ietf.org/html/draft-cheng-behave-cgn-cfg-radius-ext-03#sect >>>i >>>on- >>> 4.2 >>> >>> My concern is that operators may find it necessary to deploy all four >>> protocols (IPFIX, SYSLOG, SNMP, and RADIUS) to get their needed logging >>>and. >>> This seems undesirable. Imagine, for example, that only one of those >>> protocols supported pseudo-random port assignment but only one other >>> protocol provided alarms for when a subscriber consumed all their ports >>>(and >>> thus might open a support case with the operator that "the Internet is >>> down"). >>> >>> Are my concerns misplaced? >>> >>> -d >>> >>> >>> _______________________________________________ >>> 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 zhangzhongjian@huawei.com Mon Jul 16 20:38:44 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD70921F8512 for ; Mon, 16 Jul 2012 20:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id px9KZAU5lEMC for ; Mon, 16 Jul 2012 20:38:44 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 56BC421F850F for ; Mon, 16 Jul 2012 20:38:44 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHU89619; Mon, 16 Jul 2012 23:39:30 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 16 Jul 2012 20:36:43 -0700 Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 16 Jul 2012 20:36:42 -0700 Received: from SZXEML524-MBS.china.huawei.com ([169.254.5.229]) by szxeml417-hub.china.huawei.com ([10.82.67.156]) with mapi id 14.01.0323.003; Tue, 17 Jul 2012 11:36:36 +0800 From: "Zhangzongjian (Thomas)" To: "behave@ietf.org" Thread-Topic: this is a test mail Thread-Index: Ac1jzVvgHfK2q7oAQaulXyHDDZ7I/A== Date: Tue, 17 Jul 2012 03:36:36 +0000 Message-ID: <0B2F754289D27B449F7F1B95456B77544EDB6D98@szxeml524-mbs.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AjE9 CnrG DBst DFiH Eov3 FDhQ FjHz GSJo GgHJ HnyU IOLQ IXON Ip+A I6pe Jb8/ KKzl; 1; YgBlAGgAYQB2AGUAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {B9D95FB0-EA61-428B-A50F-1530886575CE}; egBoAGEAbgBnAHoAaABvAG4AZwBqAGkAYQBuAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Tue, 17 Jul 2012 03:36:32 GMT; dABoAGkAcwAgAGkAcwAgAGEAIAB0AGUAcwB0ACAAbQBhAGkAbAA= x-cr-puzzleid: {B9D95FB0-EA61-428B-A50F-1530886575CE} x-originating-ip: [10.66.77.96] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [BEHAVE] this is a test mail X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 03:38:45 -0000 Hi Best regards Yours Thomas From simon.perreault@viagenie.ca Thu Jul 19 05:50:43 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 751C621F87BC; Thu, 19 Jul 2012 05:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.085, 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 Jb0kNX9Nhz6i; Thu, 19 Jul 2012 05:50:42 -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 EF7DD21F87BA; Thu, 19 Jul 2012 05:50:41 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:cd29:16aa:f6fd:52fe]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 1EB2A42664; Thu, 19 Jul 2012 08:51:24 -0400 (EDT) Message-ID: <500802CB.5010908@viagenie.ca> Date: Thu, 19 Jul 2012 08:51:23 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: "behave@ietf.org" References: <5007C972.9020402@neclab.eu> In-Reply-To: <5007C972.9020402@neclab.eu> X-Forwarded-Message-Id: <5007C972.9020402@neclab.eu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: pcp@ietf.org Subject: [BEHAVE] Fwd: Re: Martin Stiemerling's Discuss on draft-ietf-behave-lsn-requirements-08: (with DISCUSS and COMMENT) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 12:50:43 -0000 Behaviers, PCPers, During IESG review of draft-ietf-behave-lsn-requirements, a DISCUSS was filed regarding the PCP requirement. Details below. I think this DISCUSS needs to be discussed. So please discuss. Please reply to behave@ietf.org. Thanks, Simon -------- Message original -------- Sujet: Re: Martin Stiemerling's Discuss on draft-ietf-behave-lsn-requirements-08: (with DISCUSS and COMMENT) Date : Thu, 19 Jul 2012 10:46:42 +0200 De : Martin Stiemerling Pour : Simon Perreault Copie à : The IESG , , Hi Simon, all, On 07/17/2012 11:11 PM, Simon Perreault wrote: > Le 2012-07-17 16:42, Martin Stiemerling a écrit : >>> Each and every CGN MUST have PCP and MUST follow the constraints. I'll >>> fix the text in a later revision. >> >> Can we mandate a specific protocol to be used for this or can we only >> mandate that such a type of protocol is being used? I don't see the IETF >> in the position to mandate this type of protocol for CGNs. >> >> There are other protocols out there which might be suitable. Note that I >> am co-author of some, but this isn't the reason for the question. I do >> not get any reward if I promote these protocols. >> >> It is more: >> do we need to constrain CGN deployments to a protocol (PCP) which is >> developed right now, or are we open to existing or future protocols, or >> whatever folks deploying this deem right? >> >> I would propose to change REQ-9 to : >> REQ-9: A CGN MUST include a middlebox control protocol that allows >> manipulation of CGN bindings with the following contstraints > A and B> >> REQ-9a: If PCP is used these contstraints MUST be applied in addition to >> contraints A and B: >> > > That was discussed in IETF 81 (Québec). Here's the extract from the > minutes: > > Stuart Cheshire: ietf has one port forwarding protocol, which > is PCP, so we should require it by name There are multiple middlebox control protocols published by the IETF (standards track and experimental) and I have not seen any call for consensus on what **the** IETF's middlebox control is, neither I have seen any RFC that states this. I do not see that an individual can declare IETF consensus based on his own opinion. > > Dave Thaler: I agree. PCP doc is in final stages. Again, an opinion of an individual. Nothing wrong about it, but it does not state IETF consensus. > > There was consensus from the WG. In consequence, the text was changed > from this (-02): > > A CGN SHOULD support a port forwarding protocol such as the > Port Control Protocol [I-D.ietf-pcp-base]. > > to this (-03): > > A CGN SHOULD include a Port Control Protocol server > [I-D.ietf-pcp-base]. > > (That requirement later became a MUST, but that's orthogonal to what > protocol we require.) I do not see that the IETF can mandate what protocols are being used to control a device. The market will decide! For instance, the is no MUST required that routers implement BGP. It is good to do this, but if one decides to go for IS-IS (or whatever) that is just fine. Another example, there is also no MUST requirement that routers, or hosts in general, have to implement SNMP. However, I can see the immediate need to mandate that a CGN SHOULD/MUST support a middlebox control protocol that is able to install and maintain NAT bindings. Martin -- martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 283 From hannes.tschofenig@gmx.net Thu Jul 19 09:04:28 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D49F721F87C8 for ; Thu, 19 Jul 2012 09:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.617 X-Spam-Level: X-Spam-Status: No, score=-102.617 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3AgsmPX-xsMI for ; Thu, 19 Jul 2012 09:04:27 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id EBCF221F87BF for ; Thu, 19 Jul 2012 09:04:26 -0700 (PDT) Received: (qmail invoked by alias); 19 Jul 2012 16:05:18 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.102]) [88.115.216.191] by mail.gmx.net (mp019) with SMTP; 19 Jul 2012 18:05:18 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+B5j0CtcuBzmBM6QNxkAUsHw2Kb93VERE5qplq5F 0LiC6+21RlgFHz Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Hannes Tschofenig In-Reply-To: <500802CB.5010908@viagenie.ca> Date: Thu, 19 Jul 2012 19:05:17 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5007C972.9020402@neclab.eu> <500802CB.5010908@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "behave@ietf.org" , pcp@ietf.org Subject: Re: [BEHAVE] [pcp] Fwd: Re: Martin Stiemerling's Discuss on draft-ietf-behave-lsn-requirements-08: (with DISCUSS and COMMENT) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 16:04:29 -0000 I agree with Martin's remarks. On Jul 19, 2012, at 3:51 PM, Simon Perreault wrote: > Behaviers, PCPers, >=20 > During IESG review of draft-ietf-behave-lsn-requirements, a DISCUSS = was filed regarding the PCP requirement. Details below. >=20 > I think this DISCUSS needs to be discussed. So please discuss. >=20 > Please reply to behave@ietf.org. >=20 > Thanks, > Simon >=20 >=20 > -------- Message original -------- > Sujet: Re: Martin Stiemerling's Discuss on = draft-ietf-behave-lsn-requirements-08: (with DISCUSS and COMMENT) > Date : Thu, 19 Jul 2012 10:46:42 +0200 > De : Martin Stiemerling > Pour : Simon Perreault > Copie =E0 : The IESG , , = >=20 > Hi Simon, all, >=20 > On 07/17/2012 11:11 PM, Simon Perreault wrote: >> Le 2012-07-17 16:42, Martin Stiemerling a =E9crit : >>>> Each and every CGN MUST have PCP and MUST follow the constraints. = I'll >>>> fix the text in a later revision. >>>=20 >>> Can we mandate a specific protocol to be used for this or can we = only >>> mandate that such a type of protocol is being used? I don't see the = IETF >>> in the position to mandate this type of protocol for CGNs. >>>=20 >>> There are other protocols out there which might be suitable. Note = that I >>> am co-author of some, but this isn't the reason for the question. I = do >>> not get any reward if I promote these protocols. >>>=20 >>> It is more: >>> do we need to constrain CGN deployments to a protocol (PCP) which is >>> developed right now, or are we open to existing or future protocols, = or >>> whatever folks deploying this deem right? >>>=20 >>> I would propose to change REQ-9 to : >>> REQ-9: A CGN MUST include a middlebox control protocol that allows >>> manipulation of CGN bindings with the following contstraints >> A and B> >>> REQ-9a: If PCP is used these contstraints MUST be applied in = addition to >>> contraints A and B: >>> >>=20 >> That was discussed in IETF 81 (Qu=E9bec). Here's the extract from the >> minutes: >>=20 >> Stuart Cheshire: ietf has one port forwarding protocol, = which >> is PCP, so we should require it by name >=20 > There are multiple middlebox control protocols published by the IETF > (standards track and experimental) and I have not seen any call for > consensus on what **the** IETF's middlebox control is, neither I have > seen any RFC that states this. >=20 > I do not see that an individual can declare IETF consensus based on = his > own opinion. >=20 >=20 >>=20 >> Dave Thaler: I agree. PCP doc is in final stages. >=20 > Again, an opinion of an individual. Nothing wrong about it, but it = does > not state IETF consensus. >=20 >>=20 >> There was consensus from the WG. In consequence, the text was changed >> from this (-02): >>=20 >> A CGN SHOULD support a port forwarding protocol such as = the >> Port Control Protocol [I-D.ietf-pcp-base]. >>=20 >> to this (-03): >>=20 >> A CGN SHOULD include a Port Control Protocol server >> [I-D.ietf-pcp-base]. >>=20 >> (That requirement later became a MUST, but that's orthogonal to what >> protocol we require.) >=20 > I do not see that the IETF can mandate what protocols are being used = to > control a device. The market will decide! >=20 > For instance, the is no MUST required that routers implement BGP. It = is > good to do this, but if one decides to go for IS-IS (or whatever) that > is just fine. >=20 > Another example, there is also no MUST requirement that routers, or > hosts in general, have to implement SNMP. >=20 > However, I can see the immediate need to mandate that a CGN = SHOULD/MUST > support a middlebox control protocol that is able to install and > maintain NAT bindings. >=20 > Martin >=20 > --=20 > martin.stiemerling@neclab.eu >=20 > NEC Laboratories Europe - Network Research Division NEC Europe Limited > Registered Office: NEC House, 1 Victoria Road, London W3 6BL > Registered in England 283 >=20 >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From repenno@cisco.com Thu Jul 19 09:18:36 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA9D421F86A8; Thu, 19 Jul 2012 09:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqtzgVANHGZp; Thu, 19 Jul 2012 09:18:36 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id EBE5F21F8672; Thu, 19 Jul 2012 09:18:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=repenno@cisco.com; l=4947; q=dns/txt; s=iport; t=1342714769; x=1343924369; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=RKERFEEvRvV+F3yzQ8zB3/0M1fr5oEZ9M6O4ibKmd+g=; b=kXGdq0vCKKAxk9PGKOhdyvklbtcy0jFW/s444oroN5mQ7abiqm19Ma2M AbFM/ffxV6cK+OEAeIehbtP/6zmjRZAJgFfsLw3DBFLVn6suIR/mJc//a c5u0PCDKWr4HjrUbnPPBddOeCSH81Q1DCrgPHM1KETxMq/jjTzP8UKfyL 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEwzCFCtJXHB/2dsb2JhbABFuUCBB4IcBAEBAQQBAQEPAQpRBgUSAQgYIzILFBECBAENBQkZhScHgiQKAwwLnjegCIplZxQEhngDiBiNLI4jgWaCX4FW X-IronPort-AV: E=Sophos;i="4.77,615,1336348800"; d="scan'208";a="103492726" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 19 Jul 2012 16:19:29 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q6JGJTZa024543 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Jul 2012 16:19:29 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.177]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0298.004; Thu, 19 Jul 2012 11:19:25 -0500 From: "Reinaldo Penno (repenno)" To: Hannes Tschofenig , Simon Perreault Thread-Topic: [pcp] Fwd: Re: Martin Stiemerling's Discuss on draft-ietf-behave-lsn-requirements-08: (with DISCUSS and COMMENT) Thread-Index: AQHNZcpD5zVzSRWO2Ue47DGuTsCIiQ== Date: Thu, 19 Jul 2012 16:19:25 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.21.65.29] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19050.003 x-tm-as-result: No--51.962200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <1771A1264D08E74EB0B132EF74003450@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" , "behave@ietf.org" Subject: Re: [BEHAVE] [pcp] Fwd: Re: Martin Stiemerling's Discuss on draft-ietf-behave-lsn-requirements-08: (with DISCUSS and COMMENT) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 16:18:37 -0000 Humm...I'm not sure I agree. "However, if a router does implement EGP it also MUST IMPLEMENT BGP." http://www.ietf.org/rfc/rfc1812.txt Or look at the requirements for IPv6 CEs or any other device that needs to interoperate with others. On 7/19/12 9:05 AM, "Hannes Tschofenig" wrote: >I agree with Martin's remarks. > >On Jul 19, 2012, at 3:51 PM, Simon Perreault wrote: > >> Behaviers, PCPers, >>=20 >> During IESG review of draft-ietf-behave-lsn-requirements, a DISCUSS was >>filed regarding the PCP requirement. Details below. >>=20 >> I think this DISCUSS needs to be discussed. So please discuss. >>=20 >> Please reply to behave@ietf.org. >>=20 >> Thanks, >> Simon >>=20 >>=20 >> -------- Message original -------- >> Sujet: Re: Martin Stiemerling's Discuss on >>draft-ietf-behave-lsn-requirements-08: (with DISCUSS and COMMENT) >> Date : Thu, 19 Jul 2012 10:46:42 +0200 >> De : Martin Stiemerling >> Pour : Simon Perreault >> Copie =E0 : The IESG , , >> >>=20 >> Hi Simon, all, >>=20 >> On 07/17/2012 11:11 PM, Simon Perreault wrote: >>> Le 2012-07-17 16:42, Martin Stiemerling a =E9crit : >>>>> Each and every CGN MUST have PCP and MUST follow the constraints. >>>>>I'll >>>>> fix the text in a later revision. >>>>=20 >>>> Can we mandate a specific protocol to be used for this or can we only >>>> mandate that such a type of protocol is being used? I don't see the >>>>IETF >>>> in the position to mandate this type of protocol for CGNs. >>>>=20 >>>> There are other protocols out there which might be suitable. Note >>>>that I >>>> am co-author of some, but this isn't the reason for the question. I do >>>> not get any reward if I promote these protocols. >>>>=20 >>>> It is more: >>>> do we need to constrain CGN deployments to a protocol (PCP) which is >>>> developed right now, or are we open to existing or future protocols, >>>>or >>>> whatever folks deploying this deem right? >>>>=20 >>>> I would propose to change REQ-9 to : >>>> REQ-9: A CGN MUST include a middlebox control protocol that allows >>>> manipulation of CGN bindings with the following contstraints >>>items >>>> A and B> >>>> REQ-9a: If PCP is used these contstraints MUST be applied in addition >>>>to >>>> contraints A and B: >>>> >>>=20 >>> That was discussed in IETF 81 (Qu=E9bec). Here's the extract from the >>> minutes: >>>=20 >>> Stuart Cheshire: ietf has one port forwarding protocol, which >>> is PCP, so we should require it by name >>=20 >> There are multiple middlebox control protocols published by the IETF >> (standards track and experimental) and I have not seen any call for >> consensus on what **the** IETF's middlebox control is, neither I have >> seen any RFC that states this. >>=20 >> I do not see that an individual can declare IETF consensus based on his >> own opinion. >>=20 >>=20 >>>=20 >>> Dave Thaler: I agree. PCP doc is in final stages. >>=20 >> Again, an opinion of an individual. Nothing wrong about it, but it does >> not state IETF consensus. >>=20 >>>=20 >>> There was consensus from the WG. In consequence, the text was changed >>> from this (-02): >>>=20 >>> A CGN SHOULD support a port forwarding protocol such as the >>> Port Control Protocol [I-D.ietf-pcp-base]. >>>=20 >>> to this (-03): >>>=20 >>> A CGN SHOULD include a Port Control Protocol server >>> [I-D.ietf-pcp-base]. >>>=20 >>> (That requirement later became a MUST, but that's orthogonal to what >>> protocol we require.) >>=20 >> I do not see that the IETF can mandate what protocols are being used to >> control a device. The market will decide! >>=20 >> For instance, the is no MUST required that routers implement BGP. It is >> good to do this, but if one decides to go for IS-IS (or whatever) that >> is just fine. >>=20 >> Another example, there is also no MUST requirement that routers, or >> hosts in general, have to implement SNMP. >>=20 >> However, I can see the immediate need to mandate that a CGN SHOULD/MUST >> support a middlebox control protocol that is able to install and >> maintain NAT bindings. >>=20 >> Martin >>=20 >> --=20 >> martin.stiemerling@neclab.eu >>=20 >> NEC Laboratories Europe - Network Research Division NEC Europe Limited >> Registered Office: NEC House, 1 Victoria Road, London W3 6BL >> Registered in England 283 >>=20 >>=20 >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp From ietfdbh@comcast.net Thu Jul 19 09:23:31 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A7D021F860B for ; Thu, 19 Jul 2012 09:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OrWF4ppVL6dN for ; Thu, 19 Jul 2012 09:23:30 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 37C9721F85E3 for ; Thu, 19 Jul 2012 09:23:30 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta02.westchester.pa.mail.comcast.net with comcast id cAxh1j0030mv7h051GQSRT; Thu, 19 Jul 2012 16:24:26 +0000 Received: from [192.168.1.67] ([184.39.8.144]) by omta11.westchester.pa.mail.comcast.net with comcast id cGQ71j00b36TH603XGQAU1; Thu, 19 Jul 2012 16:24:19 +0000 User-Agent: Microsoft-MacOutlook/14.2.2.120421 Date: Thu, 19 Jul 2012 12:24:08 -0400 From: David Harrington To: "behave@ietf.org" Message-ID: Thread-Topic: [BEHAVE] Fwd: Re: Martin Stiemerling's Discuss on draft-ietf-behave-lsn-requirements-08: (with DISCUSS and COMMENT) In-Reply-To: <500802CB.5010908@viagenie.ca> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: ietf@ietf.org Subject: Re: [BEHAVE] Fwd: Re: Martin Stiemerling's Discuss on draft-ietf-behave-lsn-requirements-08: (with DISCUSS and COMMENT) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 16:23:31 -0000 Hi, (I restricted this response to behave wg, since that is where lsn-requirements is chartered, not pcp wg; I added ietf@ietf.org since this is about a DISCUSS relating to ietf consensus). I think we should mandate something if interoperability will break if it is not done. But if the port-control aspect can be achieved using proprietary protocols with no impact on cgn operations, then a specific protocol should not be mandated. -- REQUIREMENTS for COMPLIANCE -- I frequently refer to the logic in the "Strong Security" BCP (RFC3365), which makes a distinction between what MUST be implemented in a compliant implementation, and what SHOULD be used by operators for interoperability between network elements. If an operator wants to set up a lsn-requirements-compliant CGN in a multi-vendor environment, will it be problematic if vendor A uses A-style port control, vendor B uses B-style port control, vendor C uses PCP, vendor D uses MIDCOM-MIB, and vendor E uses Diameter NAT control? If so, then there would seem to be justification to specify that **to be compliant to the IETF lsn-requirements standard/BCP/InformationalRFC recommendation** PCP MUST be implemented, so it is AVAILABLE if an operator chooses to use it. If implementers don't implement it in product, it won't be there for operators to use to achieve interoperability. Of course, a similar argument might justify also requiring implementation of Diameter NAT control and the MIDCOM-MIB. Do we want to require one specific standard as THE solution required to be compliant to this lsn-requirements standard, or do we want to provide a toolkit of multiple must-implement standards plus advice about how to combine them, and a deployer gets to choose which to use together, or do we want to specify a toolkit of implementation-optional standards that might be available and a deployer needs to figure out how to make the available options work together? Requiring PCP for compliance does not mean a vendor is required to implement PCP, any more than a vendor is required to implement BGP, but if a vendor claims to be BGP compliant, then there are aspects of BGP, or other standards that BGP relies upon being present, that MUST be there. If an implementer wants to claim compliance to the NAT-MIB, they MUST also implement ifIndex (and presumably SNMP to access the MIB). If a vendor claims to be compliant to the lsn-requirements standard (or BCP or Informational RFCXXXX) then they MUST implement those aspects that are required for compliance. Now, in the security world, where security is a system-wide process, if using multiple algorithms can create hard-to-detect security holes, there is strong justification for REQUIRING specific protocols be used across devices/vendors to avoid introducing such holes into the system. And, in the security world, there is a whole community of attackers looking for those holes so they can take advantage of such weaknesses in the overall security system. If CGN interoperability is not significantly impacted by having multiple types of port forwarding or other middlebox algorithms rather than a single algorithm, other than extra work for operators, then we probably should not REQUIRE, but simply RECOMMEND a standards-based solution such as PCP. We should NOT require it just because we want to see vendors use our protocols; that is a market-driven decision to be made by vendors based on customer demand. -- David Harrington Internet Engineering Task Force (IETF) Ietfdbh@comcast.net +1-603-828-1401 On 7/19/12 8:51 AM, "Simon Perreault" wrote: >Behaviers, PCPers, > >During IESG review of draft-ietf-behave-lsn-requirements, a DISCUSS was >filed regarding the PCP requirement. Details below. > >I think this DISCUSS needs to be discussed. So please discuss. > >Please reply to behave@ietf.org. > >Thanks, >Simon > > >-------- Message original -------- >Sujet: Re: Martin Stiemerling's Discuss on >draft-ietf-behave-lsn-requirements-08: (with DISCUSS and COMMENT) >Date : Thu, 19 Jul 2012 10:46:42 +0200 >De : Martin Stiemerling >Pour : Simon Perreault >Copie =E0 : The IESG , , > > >Hi Simon, all, > >On 07/17/2012 11:11 PM, Simon Perreault wrote: >> Le 2012-07-17 16:42, Martin Stiemerling a =E9crit : >>>> Each and every CGN MUST have PCP and MUST follow the constraints. I'll >>>> fix the text in a later revision. >>> >>> Can we mandate a specific protocol to be used for this or can we only >>> mandate that such a type of protocol is being used? I don't see the >>>IETF >>> in the position to mandate this type of protocol for CGNs. >>> >>> There are other protocols out there which might be suitable. Note that >>>I >>> am co-author of some, but this isn't the reason for the question. I do >>> not get any reward if I promote these protocols. >>> >>> It is more: >>> do we need to constrain CGN deployments to a protocol (PCP) which is >>> developed right now, or are we open to existing or future protocols, or >>> whatever folks deploying this deem right? >>> >>> I would propose to change REQ-9 to : >>> REQ-9: A CGN MUST include a middlebox control protocol that allows >>> manipulation of CGN bindings with the following contstraints >>items >>> A and B> >>> REQ-9a: If PCP is used these contstraints MUST be applied in addition >>>to >>> contraints A and B: >>> >> >> That was discussed in IETF 81 (Qu=E9bec). Here's the extract from the >> minutes: >> >> Stuart Cheshire: ietf has one port forwarding protocol, which >> is PCP, so we should require it by name > >There are multiple middlebox control protocols published by the IETF >(standards track and experimental) and I have not seen any call for >consensus on what **the** IETF's middlebox control is, neither I have >seen any RFC that states this. > >I do not see that an individual can declare IETF consensus based on his >own opinion. > > >> >> Dave Thaler: I agree. PCP doc is in final stages. > >Again, an opinion of an individual. Nothing wrong about it, but it does >not state IETF consensus. > >> >> There was consensus from the WG. In consequence, the text was changed >> from this (-02): >> >> A CGN SHOULD support a port forwarding protocol such as the >> Port Control Protocol [I-D.ietf-pcp-base]. >> >> to this (-03): >> >> A CGN SHOULD include a Port Control Protocol server >> [I-D.ietf-pcp-base]. >> >> (That requirement later became a MUST, but that's orthogonal to what >> protocol we require.) > >I do not see that the IETF can mandate what protocols are being used to >control a device. The market will decide! > >For instance, the is no MUST required that routers implement BGP. It is >good to do this, but if one decides to go for IS-IS (or whatever) that >is just fine. > >Another example, there is also no MUST requirement that routers, or >hosts in general, have to implement SNMP. > >However, I can see the immediate need to mandate that a CGN SHOULD/MUST >support a middlebox control protocol that is able to install and >maintain NAT bindings. > > Martin > >--=20 >martin.stiemerling@neclab.eu > >NEC Laboratories Europe - Network Research Division NEC Europe Limited >Registered Office: NEC House, 1 Victoria Road, London W3 6BL >Registered in England 283 > > >_______________________________________________ >Behave mailing list >Behave@ietf.org >https://www.ietf.org/mailman/listinfo/behave From ietfdbh@comcast.net Thu Jul 19 09:37:29 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89B4621F87C7 for ; Thu, 19 Jul 2012 09:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.059 X-Spam-Level: X-Spam-Status: No, score=-102.059 tagged_above=-999 required=5 tests=[AWL=0.541, 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 KhJ4lCUGJb9x for ; Thu, 19 Jul 2012 09:37:28 -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 E578D21F87BF for ; Thu, 19 Jul 2012 09:37:27 -0700 (PDT) Received: from omta04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by qmta09.emeryville.ca.mail.comcast.net with comcast id cGBw1j0030lTkoCA9GeH5U; Thu, 19 Jul 2012 16:38:17 +0000 Received: from [192.168.1.67] ([184.39.8.144]) by omta04.emeryville.ca.mail.comcast.net with comcast id cGdv1j00W36TH608QGdzdk; Thu, 19 Jul 2012 16:38:15 +0000 User-Agent: Microsoft-MacOutlook/14.2.2.120421 Date: Thu, 19 Jul 2012 12:37:55 -0400 From: David Harrington To: Simon Perreault , "behave@ietf.org" Message-ID: Thread-Topic: draft-ietf-behave-lsn-requirements - BCP, STD, AS, or Informational? In-Reply-To: <500802CB.5010908@viagenie.ca> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: iesg@ietf.org, IETF Subject: [BEHAVE] draft-ietf-behave-lsn-requirements - BCP, STD, AS, or Informational? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 16:37:30 -0000 -- BCP or not? -- As previously-responsible AD for behave, I have had serious concerns about this document being published as a BCP. =20 In another email, I discussed whether PCP should be required to be compliant to this BCP. I think the IETF needs to decide whether lsn-requirements is something to be compliant to. The title and BCP status seem rather misleading, in my opinion.=20 Following RFC3365, MUST is for implementers; SHOULD is for deployers. If we want to require vendors to implement specific features in a manner COMPLIANT to this specification, then this really should be a standard, not a BCP.=20 If we want to standardize implementation behaviors, then I think this should be an explicit standard, not some other type of RFC that will implicitly be a standard but with possibly less scrutiny than an explicit standard would generate. A BCP often carries similar weight to a standard, and I question whether some of these requirements are best CURRENT practice, especially if PCP is a MUST. It might be best DESIRED practice, or best RECOMMENDED practice, but I doubt some of these requirements are best CURRENT practice. If we simply want to document what some existing deployments are doing, then I think an Applicability statement or an Informational RFC might be more appropriate than a BCP. I think this should be a BCP only if there is a strong consensus that this is the way deployments SHOULD be done, based on actual deployment experience by a variety of operators using current implementations - that would represent best CURRENT practices. -- David Harrington Internet Engineering Task Force (IETF) Ietfdbh@comcast.net +1-603-828-1401 On 7/19/12 8:51 AM, "Simon Perreault" wrote: >Behaviers, PCPers, > >During IESG review of draft-ietf-behave-lsn-requirements, a DISCUSS was >filed regarding the PCP requirement. Details below. > >I think this DISCUSS needs to be discussed. So please discuss. > >Please reply to behave@ietf.org. > >Thanks, >Simon > > >-------- Message original -------- >Sujet: Re: Martin Stiemerling's Discuss on >draft-ietf-behave-lsn-requirements-08: (with DISCUSS and COMMENT) >Date : Thu, 19 Jul 2012 10:46:42 +0200 >De : Martin Stiemerling >Pour : Simon Perreault >Copie =E0 : The IESG , , > > >Hi Simon, all, > >On 07/17/2012 11:11 PM, Simon Perreault wrote: >> Le 2012-07-17 16:42, Martin Stiemerling a =E9crit : >>>> Each and every CGN MUST have PCP and MUST follow the constraints. I'll >>>> fix the text in a later revision. >>> >>> Can we mandate a specific protocol to be used for this or can we only >>> mandate that such a type of protocol is being used? I don't see the >>>IETF >>> in the position to mandate this type of protocol for CGNs. >>> >>> There are other protocols out there which might be suitable. Note that >>>I >>> am co-author of some, but this isn't the reason for the question. I do >>> not get any reward if I promote these protocols. >>> >>> It is more: >>> do we need to constrain CGN deployments to a protocol (PCP) which is >>> developed right now, or are we open to existing or future protocols, or >>> whatever folks deploying this deem right? >>> >>> I would propose to change REQ-9 to : >>> REQ-9: A CGN MUST include a middlebox control protocol that allows >>> manipulation of CGN bindings with the following contstraints >>items >>> A and B> >>> REQ-9a: If PCP is used these contstraints MUST be applied in addition >>>to >>> contraints A and B: >>> >> >> That was discussed in IETF 81 (Qu=E9bec). Here's the extract from the >> minutes: >> >> Stuart Cheshire: ietf has one port forwarding protocol, which >> is PCP, so we should require it by name > >There are multiple middlebox control protocols published by the IETF >(standards track and experimental) and I have not seen any call for >consensus on what **the** IETF's middlebox control is, neither I have >seen any RFC that states this. > >I do not see that an individual can declare IETF consensus based on his >own opinion. > > >> >> Dave Thaler: I agree. PCP doc is in final stages. > >Again, an opinion of an individual. Nothing wrong about it, but it does >not state IETF consensus. > >> >> There was consensus from the WG. In consequence, the text was changed >> from this (-02): >> >> A CGN SHOULD support a port forwarding protocol such as the >> Port Control Protocol [I-D.ietf-pcp-base]. >> >> to this (-03): >> >> A CGN SHOULD include a Port Control Protocol server >> [I-D.ietf-pcp-base]. >> >> (That requirement later became a MUST, but that's orthogonal to what >> protocol we require.) > >I do not see that the IETF can mandate what protocols are being used to >control a device. The market will decide! > >For instance, the is no MUST required that routers implement BGP. It is >good to do this, but if one decides to go for IS-IS (or whatever) that >is just fine. > >Another example, there is also no MUST requirement that routers, or >hosts in general, have to implement SNMP. > >However, I can see the immediate need to mandate that a CGN SHOULD/MUST >support a middlebox control protocol that is able to install and >maintain NAT bindings. > > Martin > >--=20 >martin.stiemerling@neclab.eu > >NEC Laboratories Europe - Network Research Division NEC Europe Limited >Registered Office: NEC House, 1 Victoria Road, London W3 6BL >Registered in England 283 > > >_______________________________________________ >Behave mailing list >Behave@ietf.org >https://www.ietf.org/mailman/listinfo/behave From hartmans@painless-security.com Thu Jul 19 06:02:10 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F40121F87D3; Thu, 19 Jul 2012 06:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.228 X-Spam-Level: X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 DzSOMyt2duAJ; Thu, 19 Jul 2012 06:02:09 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id A831C21F87D2; Thu, 19 Jul 2012 06:02:09 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id F27AB203BA; Thu, 19 Jul 2012 09:03:18 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id DE6A941F0; Thu, 19 Jul 2012 09:02:33 -0400 (EDT) From: Sam Hartman To: Simon Perreault References: <5007C972.9020402@neclab.eu> <500802CB.5010908@viagenie.ca> Date: Thu, 19 Jul 2012 09:02:33 -0400 In-Reply-To: <500802CB.5010908@viagenie.ca> (Simon Perreault's message of "Thu, 19 Jul 2012 08:51:23 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Thu, 19 Jul 2012 09:37:49 -0700 Cc: pcp@ietf.org, "behave@ietf.org" Subject: Re: [BEHAVE] [pcp] Fwd: Re: Martin Stiemerling's Discuss on draft-ietf-behave-lsn-requirements-08: (with DISCUSS and COMMENT) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 13:02:10 -0000 I think that behave-lsn-requirements is far more useful if it names a specific protocol by name. By endorcing one of our middlebox protocols, we encourage interoperability. If we don't pick a protocol by name, we don't really promote interoperability. It's not useful if your CGN does midcom and my client does PCP and I'm your customer. The assumption behind LSN-requirements is that the CGN and the CPE are not controlled/purchased/whatever by the same entity. So, mandating a specific protocol seems desirable. I think that the behave WG is the right place to make that decision. The IETF as a whole should be able to second guess behave, but we should need a fairly high bar for doing so. The claim that PCP is the IETF's only protocol in this space does seem a little bit on the wishful thinking side of things. So, I could understand if the IESG wanted to ask behave to spend a little more time on the question. From repenno@cisco.com Thu Jul 19 10:11:14 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2B921F87E6; Thu, 19 Jul 2012 10:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HvBoPqc2ZqYP; Thu, 19 Jul 2012 10:11:13 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id A18F521F87E4; Thu, 19 Jul 2012 10:11:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6502; q=dns/txt; s=iport; t=1342717926; x=1343927526; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=oZ69sJQqJFnfkClb8r4rg//vVjz1GD/GyO2Clxf7454=; b=KNmLZwWGuEqSL4iaa/Bi4w0w4xS59JLQ2PhJwX9/39souRqaLdQfnp96 j8Mdv5Fe2dEXBqYICz1qws58TEVPLW2AAPpG8tlb74kWNP9kObo08/Xfz RuYcMG25J3iSwpqiZ7vs4H3T8PK83me9yRi76uftC4CYpSJyqFCw5XaW/ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABI/CFCtJV2b/2dsb2JhbABCA7lEgQeCIAEBAQQBAQEPAQpKBwYFEgEIDgpVCxQRAgQBDQUih1wDDAueRJYsCIlPBItMFASDV4MhA4gYjSyOI4Fmgl+BVgk X-IronPort-AV: E=Sophos;i="4.77,615,1336348800"; d="scan'208";a="100515019" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 19 Jul 2012 17:12:05 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q6JHC54I002461 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Jul 2012 17:12:05 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.177]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0298.004; Thu, 19 Jul 2012 12:12:03 -0500 From: "Reinaldo Penno (repenno)" To: David Harrington , Simon Perreault , "behave@ietf.org" Thread-Topic: [BEHAVE] draft-ietf-behave-lsn-requirements - BCP, STD, AS, or Informational? Thread-Index: AQHNZdGd4VOtsRAYKkSfWXI2h7Ii2A== Date: Thu, 19 Jul 2012 17:12:03 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.21.88.205] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19050.003 x-tm-as-result: No--63.367400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <54530AFEEBC48B4C87F761F8FFCAEA48@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "iesg@ietf.org" , IETF Subject: Re: [BEHAVE] draft-ietf-behave-lsn-requirements - BCP, STD, AS, or Informational? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 17:11:14 -0000 Good point, some data in this regards: All previous behave RFCs that 'standardized' NAT behavior are BCPs (RFC4787, 5508, etc). And they are have lots of MUSTs On 7/19/12 9:37 AM, "David Harrington" wrote: >-- BCP or not? -- > >As previously-responsible AD for behave, I have had serious concerns about >this document being published as a BCP. >=20 > >In another email, I discussed whether PCP should be required to be >compliant to this BCP. > >I think the IETF needs to decide whether lsn-requirements is something to >be compliant to. The title and BCP status seem rather misleading, in my >opinion.=20 >Following RFC3365, MUST is for implementers; SHOULD is for deployers. If >we want to require vendors to implement specific features in a manner >COMPLIANT to this specification, then this really should be a standard, >not a BCP.=20 >If we want to standardize implementation behaviors, then I think this >should be an explicit standard, not some other type of RFC that will >implicitly be a standard but with possibly less scrutiny than an explicit >standard would generate. > > >A BCP often carries similar weight to a standard, and I question whether >some of these requirements are best CURRENT practice, especially if PCP is >a MUST. It might be best DESIRED practice, or best RECOMMENDED practice, >but I doubt some of these requirements are best CURRENT practice. If we >simply want to document what some existing deployments are doing, then I >think an Applicability statement or an Informational RFC might be more >appropriate than a BCP. I think this should be a BCP only if there is a >strong consensus that this is the way deployments SHOULD be done, based on >actual deployment experience by a variety of operators using current >implementations - that would represent best CURRENT practices. > > >-- >David Harrington >Internet Engineering Task Force (IETF) >Ietfdbh@comcast.net >+1-603-828-1401 > > > > > >On 7/19/12 8:51 AM, "Simon Perreault" wrote: > >>Behaviers, PCPers, >> >>During IESG review of draft-ietf-behave-lsn-requirements, a DISCUSS was >>filed regarding the PCP requirement. Details below. >> >>I think this DISCUSS needs to be discussed. So please discuss. >> >>Please reply to behave@ietf.org. >> >>Thanks, >>Simon >> >> >>-------- Message original -------- >>Sujet: Re: Martin Stiemerling's Discuss on >>draft-ietf-behave-lsn-requirements-08: (with DISCUSS and COMMENT) >>Date : Thu, 19 Jul 2012 10:46:42 +0200 >>De : Martin Stiemerling >>Pour : Simon Perreault >>Copie =E0 : The IESG , , >> >> >>Hi Simon, all, >> >>On 07/17/2012 11:11 PM, Simon Perreault wrote: >>> Le 2012-07-17 16:42, Martin Stiemerling a =E9crit : >>>>> Each and every CGN MUST have PCP and MUST follow the constraints. >>>>>I'll >>>>> fix the text in a later revision. >>>> >>>> Can we mandate a specific protocol to be used for this or can we only >>>> mandate that such a type of protocol is being used? I don't see the >>>>IETF >>>> in the position to mandate this type of protocol for CGNs. >>>> >>>> There are other protocols out there which might be suitable. Note that >>>>I >>>> am co-author of some, but this isn't the reason for the question. I do >>>> not get any reward if I promote these protocols. >>>> >>>> It is more: >>>> do we need to constrain CGN deployments to a protocol (PCP) which is >>>> developed right now, or are we open to existing or future protocols, >>>>or >>>> whatever folks deploying this deem right? >>>> >>>> I would propose to change REQ-9 to : >>>> REQ-9: A CGN MUST include a middlebox control protocol that allows >>>> manipulation of CGN bindings with the following contstraints >>>items >>>> A and B> >>>> REQ-9a: If PCP is used these contstraints MUST be applied in addition >>>>to >>>> contraints A and B: >>>> >>> >>> That was discussed in IETF 81 (Qu=E9bec). Here's the extract from the >>> minutes: >>> >>> Stuart Cheshire: ietf has one port forwarding protocol, >>>which >>> is PCP, so we should require it by name >> >>There are multiple middlebox control protocols published by the IETF >>(standards track and experimental) and I have not seen any call for >>consensus on what **the** IETF's middlebox control is, neither I have >>seen any RFC that states this. >> >>I do not see that an individual can declare IETF consensus based on his >>own opinion. >> >> >>> >>> Dave Thaler: I agree. PCP doc is in final stages. >> >>Again, an opinion of an individual. Nothing wrong about it, but it does >>not state IETF consensus. >> >>> >>> There was consensus from the WG. In consequence, the text was changed >>> from this (-02): >>> >>> A CGN SHOULD support a port forwarding protocol such as >>>the >>> Port Control Protocol [I-D.ietf-pcp-base]. >>> >>> to this (-03): >>> >>> A CGN SHOULD include a Port Control Protocol server >>> [I-D.ietf-pcp-base]. >>> >>> (That requirement later became a MUST, but that's orthogonal to what >>> protocol we require.) >> >>I do not see that the IETF can mandate what protocols are being used to >>control a device. The market will decide! >> >>For instance, the is no MUST required that routers implement BGP. It is >>good to do this, but if one decides to go for IS-IS (or whatever) that >>is just fine. >> >>Another example, there is also no MUST requirement that routers, or >>hosts in general, have to implement SNMP. >> >>However, I can see the immediate need to mandate that a CGN SHOULD/MUST >>support a middlebox control protocol that is able to install and >>maintain NAT bindings. >> >> Martin >> >>--=20 >>martin.stiemerling@neclab.eu >> >>NEC Laboratories Europe - Network Research Division NEC Europe Limited >>Registered Office: NEC House, 1 Victoria Road, London W3 6BL >>Registered in England 283 >> >> >>_______________________________________________ >>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 ietfdbh@comcast.net Thu Jul 19 11:20:52 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAB421F86B6 for ; Thu, 19 Jul 2012 11:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.445 X-Spam-Level: X-Spam-Status: No, score=-102.445 tagged_above=-999 required=5 tests=[AWL=0.154, 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 FnijYbLFLCNQ for ; Thu, 19 Jul 2012 11:20:51 -0700 (PDT) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by ietfa.amsl.com (Postfix) with ESMTP id 4C70321F86AF for ; Thu, 19 Jul 2012 11:20:51 -0700 (PDT) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta01.emeryville.ca.mail.comcast.net with comcast id cDp01j00L1Y3wxoA1JMlP1; Thu, 19 Jul 2012 18:21:45 +0000 Received: from [192.168.1.67] ([184.39.8.144]) by omta15.emeryville.ca.mail.comcast.net with comcast id cJLu1j00K36TH608bJM1R5; Thu, 19 Jul 2012 18:21:39 +0000 User-Agent: Microsoft-MacOutlook/14.2.2.120421 Date: Thu, 19 Jul 2012 14:20:53 -0400 From: David Harrington To: Sam Hartman , Simon Perreault Message-ID: Thread-Topic: [BEHAVE] [pcp] Fwd: Re: Martin Stiemerling's Discuss on draft-ietf-behave-lsn-requirements-08: (with DISCUSS and COMMENT) In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: pcp@ietf.org, "behave@ietf.org" , IETF Subject: Re: [BEHAVE] [pcp] Fwd: Re: Martin Stiemerling's Discuss on draft-ietf-behave-lsn-requirements-08: (with DISCUSS and COMMENT) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 18:20:52 -0000 On 7/19/12 9:02 AM, "Sam Hartman" wrote: >I think that behave-lsn-requirements is far more useful if it names a >specific protocol by name. By endorcing one of our middlebox protocols, >we encourage interoperability. If we don't pick a protocol by name, we >don't really promote interoperability. It's not useful if your CGN does >midcom and my client does PCP and I'm your customer. The assumption >behind LSN-requirements is that the CGN and the CPE are not >controlled/purchased/whatever by the same entity. So, mandating a >specific protocol seems desirable. The IETF could mandate a specific protocol to try to ensure interoperability, but doing this takes the decision out of the responsibility of the deployer to choose the best solution for the deployment environment, and out of the responsibility of the vendor to best meet their customers' demands. Some vendors already support an SNMP-based environment, and a CGN-NAT-MIB might best meet their needs. Some vendors might support a Netconf environment and desire a Netconf-based configuration solution. Some vendors already use AAA widely to control their environment, and Diameter NAT control might be preferable. Some vendors might be implementing the (not yet IETF-approved) PCP standard, and would prefer that solution. > >I think that the behave WG is the right place to make that decision. >The IETF as a whole should be able to second guess behave, but we should >need a fairly high bar for doing so. I think that **within IETF**, behave wg might have the right expertise to make this decision (technical comparison of middlebox protocols by protocol designers). Of course, no current WG has much input from proponents of the original MIDCOM WG strategy, and most Diameter proponents are not very active in behave wg. And behave DOES have an overlap between the PCP developers and behave solutions. So behave WG might be rather biased toward a specific solution (not that the bias is necessarily bad, but the bias should be recognized). Of course, if CGN is only an ipv4 exit strategy, as is asserted, then sunset4 would seem the appropriate choice, so we have one consistent ipv4 exit strategy. We already recognize that different wgs are developing ipv4 exit strategies that conflict; that's why a sunset4 wg has been approved. And if CGN **is** only for ipv4-sunsetting, a "this IETF recommendation becomes obsolete on such-and-such a date" might be appropriate for lsn-requirements. The right expertise might be in the sunset4 wg, which might have increased operator input about a complete ipv4/ipv6 transition deployment strategy rather than middlebox protocol design comparisons by middlebox protocol designers. While I would love to see consensus for a good interoperable solution, and would support ***A*** standard that says "to be compliant to THIS specification, use THIS middlebox proposal", I hesitate to say "this is the ONLY middlebox standard that is recommended or usable within IETF standards" - especially if that only recommended part has little or no actual field experience to back up the RECOMMENDED, and little or no documentation has been done of the suitability/useability in various environments of the existing IETF standards that would become NOT RECOMMENDED. I think the right place to make the decision about which midcom solution should be used in a particular environment is in the market. My cable provider lets me purchase/control my cable router (to a degree), but only certain routers are supported. I can choose which cable router offers the additional functionality/control I want for my environment. My provider has input to the decision, and so do I (to a limited extent). Of course, to a limited extent, I can also choose a different provider or get less support from my provider. > >The claim that PCP is the IETF's only protocol in this space does seem a >little bit on the wishful thinking side of things. So, I could >understand if the IESG wanted to ask behave to spend a little more time >on the question. +1 (or ask sunset4 to spend a little more time on the question). David Harrington ietfdbh@comcast.net +1-603-828-1401 From simon.perreault@viagenie.ca Thu Jul 19 11:34:26 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED73321F868A; Thu, 19 Jul 2012 11:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.082, 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 QmoWG7e5g+ob; Thu, 19 Jul 2012 11:34:25 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 269DB21F8683; Thu, 19 Jul 2012 11:34:25 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:18fd:ed02:dd69:c681]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 45F45414A1; Thu, 19 Jul 2012 14:35:18 -0400 (EDT) Message-ID: <50085365.6050701@viagenie.ca> Date: Thu, 19 Jul 2012 14:35:17 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: David Harrington References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Sam Hartman , pcp@ietf.org, "behave@ietf.org" , IETF Subject: Re: [BEHAVE] [pcp] Fwd: Re: Martin Stiemerling's Discuss on draft-ietf-behave-lsn-requirements-08: (with DISCUSS and COMMENT) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 18:34:26 -0000 Le 2012-07-19 14:20, David Harrington a écrit : > The IETF could mandate a specific protocol to try to ensure > interoperability, but doing this takes the decision out of the > responsibility of the deployer to choose the best solution for the > deployment environment, and out of the responsibility of the vendor to > best meet their customers' demands. > Some vendors already support an SNMP-based environment, and a CGN-NAT-MIB > might best meet their needs. > Some vendors might support a Netconf environment and desire a > Netconf-based configuration solution. > Some vendors already use AAA widely to control their environment, and > Diameter NAT control might be preferable. Careful here. The above protocols are not used between the CPE and the CGN. The requirement for PCP (or PCP-like) is justified by the need for subscribers to be able to control the CGN to some extent. Note also that any of those protocols could also be supported in addition to PCP, up to the implementer and operator. > Of course, if CGN is only an ipv4 exit strategy, as is asserted, Not as asserted by the draft, I hope. We have tried making clear that CGN as defined in this document really stands for "multi-user NAT" and that there are use cases that have nothing to do with IPv4 sunset (e.g. the NAT function in a wifi hotspot is a CGN). The CGN logical function may or may not be used as part of an IPv4 sunset scenario. As such, it is is absolutely part of behave's core expertise. Sunset4 could have things to say about how CGN gets applied to IPv4 sunset, but how CGN behaves is up to behave. 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 hartmans@painless-security.com Thu Jul 19 13:16:08 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F80411E809B; Thu, 19 Jul 2012 13:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.857 X-Spam-Level: X-Spam-Status: No, score=-102.857 tagged_above=-999 required=5 tests=[AWL=-0.592, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 GxAaKkdCMFMK; Thu, 19 Jul 2012 13:16:07 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 3172711E8099; Thu, 19 Jul 2012 13:16:06 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 69E72203BA; Thu, 19 Jul 2012 16:17:15 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4B22541F0; Thu, 19 Jul 2012 16:16:31 -0400 (EDT) From: Sam Hartman To: David Harrington References: Date: Thu, 19 Jul 2012 16:16:31 -0400 In-Reply-To: (David Harrington's message of "Thu, 19 Jul 2012 14:20:53 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pcp@ietf.org, "behave@ietf.org" , IETF Subject: Re: [BEHAVE] [pcp] Fwd: Re: Martin Stiemerling's Discuss on draft-ietf-behave-lsn-requirements-08: (with DISCUSS and COMMENT) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 20:16:08 -0000 >>>>> "David" == David Harrington writes: David> The IETF could mandate a specific protocol to try to ensure David> interoperability, but doing this takes the decision out of the David> responsibility of the deployer to choose the best solution for the David> deployment environment, and out of the responsibility of the vendor to David> best meet their customers' demands. This doesn't make any sense to me at all. It makes sense if the vendor that the ISP is going to use (the CGN vendor) is somehow related to the vendor that the customer is going to use (the CPE vendor). However, one of the explicitly stated assumptions in the behave-lsn document is that is not the case. The customer gets to choose a CPE vendor and the operator gets to choose a CGN vendor. The deployment environment here is the Internet. In cases like this in the past we have chosen a technology. I'm reasonably sure that host requirements mandate DNS as the name service protocol. We don't want one isp to choose some big LDAP directory and one ISP to choose DNS. We want customers name resolution to continue to work (with the same CPE they already have) as they move from one ISP to another. The same arguments apply here . Under the assumptions of this BCP, there is not a boundary between deployment environments across which one deployment could use PCP and another SNMP. (I am not aware of netconf schema that does anything similar to PCP that has been standardized.) Even obvious deployment environments like cable vs DSL don't make sense. I can buy my own router and stick it behind either a cable modem or a DSL router. People often do this. With some ISPs the configuration gets a little tricky and you may introduce an extra level of NAT. However, people deploy their own customer gateways on cable, DSL, even in some cases mobile wireless. BGP was held up as an example, namely that we don't mandate the implementation of BGP. Well, not all routers should implement BGP. My little Linksys box has no need for it. However, if we wrote requirements for routers participating in the core routing infrastructure--routers between large organizations and ISP--we'd almost certainly mandate BGP. Not all NATs need the same middlebox control protocol. However, this document does not apply to all NATs. It applies to NATs that cross organizational boundaries. That's exactly the environment where saying something like "this is an SNMP deployment," confuses me because I don't think there will be uniform characterizations of the deployment. From mperumal@cisco.com Tue Jul 24 11:34:03 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5676E11E80A3 for ; Tue, 24 Jul 2012 11:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5n3KdwY7uJRi for ; Tue, 24 Jul 2012 11:34:02 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 3199111E8087 for ; Tue, 24 Jul 2012 11:33:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=5323; q=dns/txt; s=iport; t=1343154838; x=1344364438; h=from:to:subject:date:message-id:mime-version; bh=565nFbwIdyydcTL4aVEPKtb2eyBoU7rVUW4LvLRHxoo=; b=dS1IvOJ7tOqkW+ag31xjPisYhhI1xfETIdlDxltfuvw6e4aCqqFEoUy7 sVNya9Iagif7WOderDX+mfYF47MR4rrqM6eR2iIDSSjCir09yD7PcbZkN nPNfny48igrIJFLRFu+up4uFWiPgfbSUrQHttZswFLAduROGnmPgsroJc U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAPLpDlCtJV2a/2dsb2JhbABFgkq3LoEHgiIBBBIBGl4BKlYmAQQbGodrmWeBKKBAkV9gA6NwgWaCXw X-IronPort-AV: E=Sophos;i="4.77,647,1336348800"; d="scan'208,217";a="104867252" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 24 Jul 2012 18:33:57 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q6OIXv0V014494 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 24 Jul 2012 18:33:57 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.223]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0298.004; Tue, 24 Jul 2012 13:33:57 -0500 From: "Muthu Arul Mozhi Perumal (mperumal)" To: "behave@ietf.org" Thread-Topic: STUN request retransmission example in RFC5389 Thread-Index: Ac1pyuHtWVMr3pWkRdOoBy1WOOsF0Q== Date: Tue, 24 Jul 2012 18:33:57 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.69.217] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19062.001 x-tm-as-result: No--33.323000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_E721D8C6A2E1544DB2DEBC313AF54DE2012ED8F3xmbrcdx02ciscoc_" MIME-Version: 1.0 Subject: [BEHAVE] STUN request retransmission example in RFC5389 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 18:34:03 -0000 --_000_E721D8C6A2E1544DB2DEBC313AF54DE2012ED8F3xmbrcdx02ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RFC5389 section 7.2.1 has an example for STUN request retransmissions. It s= ays: For example, assuming an RTO of 500 ms, requests would be sent at times 0 ms, 500 ms, 1500 ms, 3500 ms, 7500 ms, 15500 ms, and 31500 ms. If the client has not received a response after 39500 ms, the client will consider the transaction to have timed out. Should the second sentence actually be? If the client has not received a response after 31500 ms, the client will consider the transaction to have timed out. Not sure why it says 39500 ms. Is it an errata? Muthu --_000_E721D8C6A2E1544DB2DEBC313AF54DE2012ED8F3xmbrcdx02ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

RFC5389 section 7.2.1 has an example for STUN request retr= ansmissions. It says:

 

   For example, assuming an RTO of 500 ms,<= /o:p>

   requests would be sent at times 0 ms, 500 ms,= 1500 ms, 3500 ms, 7500

   ms, 15500 ms, and 31500 ms.  If the clie= nt has not received a

   response after 39500 ms, the client will cons= ider the transaction to

   have timed out.

 

Should the second sentence actually be?<= /p>

 

   If the client has not received a

   response after 31500 ms, the client will cons= ider the transaction to

   have timed out.

 

Not sure why it says 39500 ms. Is it an errata?=

 

Muthu

--_000_E721D8C6A2E1544DB2DEBC313AF54DE2012ED8F3xmbrcdx02ciscoc_-- From mperumal@cisco.com Tue Jul 24 11:39:09 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E8F11E8087 for ; Tue, 24 Jul 2012 11:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.548 X-Spam-Level: X-Spam-Status: No, score=-10.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afuOyXdk3K2g for ; Tue, 24 Jul 2012 11:39:08 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 8C89421F85C6 for ; Tue, 24 Jul 2012 11:39:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=9182; q=dns/txt; s=iport; t=1343155148; x=1344364748; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=z5899IXqO7MFG0TX4Tn1KNdhhoNHEPpXpOm6Yx1EICk=; b=SUMCvq53iCCzkQ6SE4H/ZW6h5E1FWyYVkgiWltuEmJcbd5pFTXKln5iY 4WG8F9bEOSMzmHY/kCQzOSuNIaHkZH6CUivUwT5vV5wx1JIrl9xv3L17F 2F19BkvtUVFS2qdANI49yhxeIEFxH1oqG5705VLxzJmxYlpwsIpNyIl57 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHrrDlCtJV2Z/2dsb2JhbABFgkq3LoEHgiABAQEEEgEaXAIBCBEEAQELHQcyFAkIAQEEEwgah2ubDKBAi0uGFGADo3CBZoJf X-IronPort-AV: E=Sophos;i="4.77,647,1336348800"; d="scan'208,217";a="104885201" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 24 Jul 2012 18:39:08 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q6OId7ta028979 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 24 Jul 2012 18:39:07 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.223]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0298.004; Tue, 24 Jul 2012 13:39:07 -0500 From: "Muthu Arul Mozhi Perumal (mperumal)" To: "behave@ietf.org" Thread-Topic: STUN request retransmission example in RFC5389 Thread-Index: Ac1pyuHtWVMr3pWkRdOoBy1WOOsF0QAAGOhA Date: Tue, 24 Jul 2012 18:39:06 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.69.217] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19062.001 x-tm-as-result: No--39.224200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_E721D8C6A2E1544DB2DEBC313AF54DE2012ED93Dxmbrcdx02ciscoc_" MIME-Version: 1.0 Subject: Re: [BEHAVE] STUN request retransmission example in RFC5389 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 18:39:09 -0000 --_000_E721D8C6A2E1544DB2DEBC313AF54DE2012ED93Dxmbrcdx02ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please ignore. I missed this one earlier: If, after the last request, a duration equal to Rm times the RTO has passed without a response (providing ample time to get a response if only this final request actually succeeds), the client SHOULD consider the transaction to have failed. Rm SHOULD be configurable and SHOULD have a default of 16. 500*16 =3D 8 sec. So the client waits 8 sec after sending the final request= at 31500 ms and times out at 39500 ms. Muthu From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of= Muthu Arul Mozhi Perumal (mperumal) Sent: Wednesday, July 25, 2012 12:04 AM To: behave@ietf.org Subject: [BEHAVE] STUN request retransmission example in RFC5389 RFC5389 section 7.2.1 has an example for STUN request retransmissions. It s= ays: For example, assuming an RTO of 500 ms, requests would be sent at times 0 ms, 500 ms, 1500 ms, 3500 ms, 7500 ms, 15500 ms, and 31500 ms. If the client has not received a response after 39500 ms, the client will consider the transaction to have timed out. Should the second sentence actually be? If the client has not received a response after 31500 ms, the client will consider the transaction to have timed out. Not sure why it says 39500 ms. Is it an errata? Muthu --_000_E721D8C6A2E1544DB2DEBC313AF54DE2012ED93Dxmbrcdx02ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please ignore. I missed this one earlier:

 

   If, after the last request, a duration

   equal to Rm times the RTO has passed without = a response (providing

   ample time to get a response if only this fin= al request actually

   succeeds), the client SHOULD consider the tra= nsaction to have failed.

   Rm SHOULD be configurable and SHOULD have a d= efault of 16.

 

500*16 =3D 8 sec. So the client waits 8 sec after sending = the final request at 31500 ms and times out at 39500 ms.

 

Muthu

 

From: behave-b= ounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of Muthu Arul Mozhi Perumal (mperumal)
Sent: Wednesday, July 25, 2012 12:04 AM
To: behave@ietf.org
Subject: [BEHAVE] STUN request retransmission example in RFC5389

 

RFC5389 section 7.2.1 has an example for STUN request retr= ansmissions. It says:

 

   For example, assuming an RTO of 500 ms,<= /o:p>

   requests would be sent at times 0 ms, 500 ms,= 1500 ms, 3500 ms, 7500

   ms, 15500 ms, and 31500 ms.  If the clie= nt has not received a

   response after 39500 ms, the client will cons= ider the transaction to

   have timed out.

 

Should the second sentence actually be?<= /p>

 

   If the client has not received a

   response after 31500 ms, the client will cons= ider the transaction to

   have timed out.

 

Not sure why it says 39500 ms. Is it an errata?=

 

Muthu

--_000_E721D8C6A2E1544DB2DEBC313AF54DE2012ED93Dxmbrcdx02ciscoc_-- From internet-drafts@ietf.org Mon Jul 30 14:16:25 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF50821F85F0; Mon, 30 Jul 2012 14:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, 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 Wavd3ZBZvdVj; Mon, 30 Jul 2012 14:16:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66F1021F85DB; Mon, 30 Jul 2012 14:16:24 -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: 4.32 Message-ID: <20120730211624.32713.66668.idtracker@ietfa.amsl.com> Date: Mon, 30 Jul 2012 14:16:24 -0700 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-11.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 21:16:25 -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 Avoida= nce Working Group of the IETF. Title : Discovery of IPv6 Prefix Used for IPv6 Address Synthesis Author(s) : Teemu Savolainen Jouni Korhonen Dan Wing Filename : draft-ietf-behave-nat64-discovery-heuristic-11.txt Pages : 18 Date : 2012-07-30 Abstract: This document describes a method for detecting the presence of DNS64 and for learning the IPv6 prefix used for protocol translation on an access network. The method depends on the existence of a well-known IPv4-only domain name "ipv4only.arpa". The information learned enables nodes to perform local IPv6 address synthesis and to potentially avoid NAT64 on dual-stack and multi-interface deployments. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-behave-nat64-discovery-heuristic There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-behave-nat64-discovery-heuristic-11 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-behave-nat64-discovery-heur= istic-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From meng.wei2@zte.com.cn Tue Jul 31 00:59:20 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D122921F866E for ; Tue, 31 Jul 2012 00:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, 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 TFCeDZcWRiSJ for ; Tue, 31 Jul 2012 00:59:20 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id BA4D921F8627 for ; Tue, 31 Jul 2012 00:59:19 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 107231419759111; Tue, 31 Jul 2012 15:46:36 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 228.1419759111; Tue, 31 Jul 2012 15:59:08 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q6V7x94s038964 for ; Tue, 31 Jul 2012 15:59:09 +0800 (GMT-8) (envelope-from meng.wei2@zte.com.cn) In-Reply-To: <20120730211624.32713.66668.idtracker@ietfa.amsl.com> To: behave@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: meng.wei2@zte.com.cn Date: Tue, 31 Jul 2012 15:59:19 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-07-31 15:59:06, Serialize complete at 2012-07-31 15:59:06 Content-Type: multipart/alternative; boundary="=_alternative 002BCA1748257A4C_=" X-MAIL: mse01.zte.com.cn q6V7x94s038964 Subject: [BEHAVE] A little doubt about draft-ietf-behave-lsn-requirements-08 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 07:59:20 -0000 This is a multipart message in MIME format. --=_alternative 002BCA1748257A4C_= Content-Type: text/plain; charset="US-ASCII" Hi, I have a little doubt about the draft. In section 3, " REQ-11: When a CGN is unable to create a mapping due to resource constraints or administrative restrictions (i.e., quotas): A. it MUST drop the original packet; B. it SHOULD send an ICMP Destination Unreachable message with code 1 (Host Unreachable) to the sender; C. it SHOULD send a notification (e.g., SNMP trap) towards a management system (if configured to do so); D. and it MUST NOT delete existing mappings in order to "make room" for the new one. (This only applies to normal CGN behavior, not to manual operator intervention.) " In item D, In my opinion, a static mapping MAY be created without recieving the datagram, but the static rule has been configured AND the corresponding user be online. Under the circumstances, if the packet a CGN recieved match the STATIC rule , it SHOULD DELETE a existing DYNAMIC mapping in order to "make room" for the STATIC mapping, because of ensuring the STATIC rule taking effect. Otherwise, how to resolve the problem instead of kicking a DYNAMIC mapping off ? On the other hand, if the packet need to be translated by ALG, it MAY create two mappings but it find that there is "no room" to create the second mapping after having created the first mapping. Thanks, Wei Meng ZTE corporation -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately. --=_alternative 002BCA1748257A4C_= Content-Type: text/html; charset="US-ASCII"
Hi,

   I have a little doubt about the draft.

   In section 3,
   "
    REQ-11:  When a CGN is unable to create a mapping due to resource
            constraints or administrative restrictions (i.e., quotas):

            A.  it MUST drop the original packet;

            B.  it SHOULD send an ICMP Destination Unreachable message
                with code 1 (Host Unreachable) to the sender;

            C.  it SHOULD send a notification (e.g., SNMP trap) towards
                a management system (if configured to do so);

            D.  and it MUST NOT delete existing mappings in order to
                "make room" for the new one.  (This only applies to
                normal CGN behavior, not to manual operator
                intervention.)
    "

    In item D, In my opinion, a static mapping MAY be created without recieving the datagram, but the static rule has been configured AND the corresponding user be online. Under the circumstances, if the packet a CGN recieved match the STATIC rule , it SHOULD DELETE a existing DYNAMIC mapping in order to "make room" for the STATIC mapping, because of ensuring the STATIC rule taking effect.
    Otherwise, how to resolve the problem instead of kicking a DYNAMIC mapping off ?
    On the other hand, if the packet need to be translated by ALG, it MAY create two mappings but it find that there is "no room" to create the second mapping after having created the first mapping.

    Thanks,
    Wei Meng
    ZTE corporation

    
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.
--=_alternative 002BCA1748257A4C_=-- From dthaler@microsoft.com Tue Jul 31 10:16:02 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88D9221F8738 for ; Tue, 31 Jul 2012 10:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.697 X-Spam-Level: X-Spam-Status: No, score=-103.697 tagged_above=-999 required=5 tests=[AWL=-0.099, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XW00GZIeX+D for ; Tue, 31 Jul 2012 10:16:02 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id 55CD521F8497 for ; Tue, 31 Jul 2012 10:16:00 -0700 (PDT) Received: from mail174-ch1-R.bigfish.com (10.43.68.243) by CH1EHSOBE011.bigfish.com (10.43.70.61) with Microsoft SMTP Server id 14.1.225.23; Tue, 31 Jul 2012 17:15:59 +0000 Received: from mail174-ch1 (localhost [127.0.0.1]) by mail174-ch1-R.bigfish.com (Postfix) with ESMTP id D288832038B for ; Tue, 31 Jul 2012 17:15:59 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: VS0(zzc85fhzz1202hzz8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail174-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail174-ch1 (localhost.localdomain [127.0.0.1]) by mail174-ch1 (MessageSwitch) id 1343754958301076_12630; Tue, 31 Jul 2012 17:15:58 +0000 (UTC) Received: from CH1EHSMHS017.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.227]) by mail174-ch1.bigfish.com (Postfix) with ESMTP id 3D938480071 for ; Tue, 31 Jul 2012 17:15:58 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS017.bigfish.com (10.43.70.17) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 31 Jul 2012 17:15:56 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.2.309.3; Tue, 31 Jul 2012 17:15:56 +0000 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) with Microsoft SMTP Server (TLS) id 14.2.309.3; Tue, 31 Jul 2012 10:15:55 -0700 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.170]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.02.0309.003; Tue, 31 Jul 2012 10:15:55 -0700 From: Dave Thaler To: "behave@ietf.org" Thread-Topic: Call for volunteers for notetaker and jabber scribe Thread-Index: Ac1vQB1mSRxKe0XATkGItV8VL/lq7Q== Date: Tue, 31 Jul 2012 17:15:54 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B7304C8@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.43] Content-Type: multipart/alternative; boundary="_000_9B57C850BB53634CACEC56EF4853FF653B7304C8TK5EX14MBXW604w_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [BEHAVE] Call for volunteers for notetaker and jabber scribe X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 17:16:02 -0000 --_000_9B57C850BB53634CACEC56EF4853FF653B7304C8TK5EX14MBXW604w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As usual, we need at least one notetaker and a jabber scribe. Please let the chairs know if you are willing to volunteer for either of these tasks. -Dave --_000_9B57C850BB53634CACEC56EF4853FF653B7304C8TK5EX14MBXW604w_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As usual, we need at least one notetaker and a jabbe= r scribe.

Please let the chairs know if you are willing to vol= unteer for

either of these tasks.

 

-Dave

 

--_000_9B57C850BB53634CACEC56EF4853FF653B7304C8TK5EX14MBXW604w_--