From jean-philippe.dionne@viagenie.ca Wed Jul 4 13:49:25 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA2A21F8692 for ; Wed, 4 Jul 2012 13:49:25 -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, HTML_MESSAGE=0.001, 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 KUZP4UAfZMDK for ; Wed, 4 Jul 2012 13:49: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 C639B21F85E1 for ; Wed, 4 Jul 2012 13:49:24 -0700 (PDT) Received: from sekkai.viagenie.ca (unknown [IPv6:2620:0:230:c000:881d:b3f:becf:6e9a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 19FC7415DE for ; Wed, 4 Jul 2012 16:49:36 -0400 (EDT) Message-ID: <4FF4AC5F.8010805@viagenie.ca> Date: Wed, 04 Jul 2012 16:49:35 -0400 From: Jean-Philippe Dionne User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0 MIME-Version: 1.0 To: sunset4@ietf.org References: <20120704204336.825.84926.idtracker@ietfa.amsl.com> In-Reply-To: <20120704204336.825.84926.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120704204336.825.84926.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------070903020409050501050603" Subject: [sunset4] Fwd: New Version Notification for draft-dionne-sunset4-v4gapanalysis-00.txt X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 20:49:25 -0000 This is a multi-part message in MIME format. --------------070903020409050501050603 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi, The following document discusses possible work for the working group. Thanks for your comments. Jean-Philippe -------- Original Message -------- Subject: New Version Notification for draft-dionne-sunset4-v4gapanalysis-00.txt Date: Wed, 04 Jul 2012 13:43:36 -0700 From: internet-drafts@ietf.org To: jean-philippe.dionne@viagenie.ca CC: simon.perreault@viagenie.ca, tina.tsou.zouting@huawei.com A new version of I-D, draft-dionne-sunset4-v4gapanalysis-00.txt has been successfully submitted by Jean-Philippe Dionne and posted to the IETF repository. Filename: draft-dionne-sunset4-v4gapanalysis Revision: 00 Title: Gap Analysis for IPv4 Sunset Creation date: 2012-07-04 WG ID: Individual Submission Number of pages: 7 URL: http://www.ietf.org/internet-drafts/draft-dionne-sunset4-v4gapanalysis-00.txt Status: http://datatracker.ietf.org/doc/draft-dionne-sunset4-v4gapanalysis Htmlized: http://tools.ietf.org/html/draft-dionne-sunset4-v4gapanalysis-00 Abstract: Sunsetting IPv4 refers to the process of turning off IPv4 definitively. It can be seen as the final phase of the migration to IPv6. This memo analyses difficulties arising when sunsetting IPv4, and identifies the gaps resulting in additional work. The IETF Secretariat --------------070903020409050501050603 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi,

The following document discusses possible work for the working group.

Thanks for your comments.

Jean-Philippe

-------- Original Message --------
Subject: New Version Notification for draft-dionne-sunset4-v4gapanalysis-00.txt
Date: Wed, 04 Jul 2012 13:43:36 -0700
From: internet-drafts@ietf.org
To: jean-philippe.dionne@viagenie.ca
CC: simon.perreault@viagenie.ca, tina.tsou.zouting@huawei.com 


A new version of I-D, draft-dionne-sunset4-v4gapanalysis-00.txt
has been successfully submitted by Jean-Philippe Dionne and posted to the
IETF repository.

Filename:	 draft-dionne-sunset4-v4gapanalysis
Revision:	 00
Title:		 Gap Analysis for IPv4 Sunset
Creation date:	 2012-07-04
WG ID:		 Individual Submission
Number of pages: 7
URL:             http://www.ietf.org/internet-drafts/draft-dionne-sunset4-v4gapanalysis-00.txt
Status:          http://datatracker.ietf.org/doc/draft-dionne-sunset4-v4gapanalysis
Htmlized:        http://tools.ietf.org/html/draft-dionne-sunset4-v4gapanalysis-00


Abstract:
   Sunsetting IPv4 refers to the process of turning off IPv4
   definitively.  It can be seen as the final phase of the migration to
   IPv6.  This memo analyses difficulties arising when sunsetting IPv4,
   and identifies the gaps resulting in additional work.

                                                                                  


The IETF Secretariat



--------------070903020409050501050603-- From liushucheng@huawei.com Wed Jul 4 20:04:01 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFA5611E8099 for ; Wed, 4 Jul 2012 20:04:01 -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.001, 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 sDfO6DSekmnf for ; Wed, 4 Jul 2012 20:04:00 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3E48011E8079 for ; Wed, 4 Jul 2012 20:04:00 -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 AHL20848; Wed, 04 Jul 2012 23:04:12 -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; Wed, 4 Jul 2012 20:03:51 -0700 Received: from SZXEML426-HUB.china.huawei.com (10.72.61.34) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 4 Jul 2012 20:03:49 -0700 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.75]) by szxeml426-hub.china.huawei.com ([10.72.61.34]) with mapi id 14.01.0323.003; Thu, 5 Jul 2012 11:03:24 +0800 From: "Will Liu (Shucheng)" To: "sunset4@ietf.org" Thread-Topic: New draft: draft-tsou-stateless-nat44.txt Thread-Index: Ac1aWrsN1Gq+lXCHRjemLv2Kl1iv/Q== Date: Thu, 5 Jul 2012 03:03:24 +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: multipart/alternative; boundary="_000_C9B5F12337F6F841B35C404CF0554ACB2B942C11szxeml546mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Marc Blanchet Subject: [sunset4] New draft: draft-tsou-stateless-nat44.txt X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 03:04:02 -0000 --_000_C9B5F12337F6F841B35C404CF0554ACB2B942C11szxeml546mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi , We have submitted a new draft entitled " draft-tsou-stateless-nat44". The i= ntent of the draft is to describe a protocol for decentralizing IPv4 NAT to= the customer-premises equipment (CPE) such that no state information is ke= pt on the central NAT device, and to discuss potential related issues. The latest version is available at: < http://www.ietf.org/id/draft-tsou-stateless-nat44-00.txt> Any comments will be appreciated. Regards, Will --_000_C9B5F12337F6F841B35C404CF0554ACB2B942C11szxeml546mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi ,

 

We have submitted a new draf= t entitled " draft-tsou-stateless-nat44". The intent of the draft= is to describe a protocol for decentralizing IPv4 NAT to the customer-prem= ises equipment (CPE) such that no state information is kept on the central NAT device, and to discuss potential related issues= .

 

The latest version is availa= ble at:

< http://www.ietf.org/id/draft-tsou-stateless-nat44-00.txt>=

 

Any comments will be appreci= ated.

 

Regards,

Will

 

--_000_C9B5F12337F6F841B35C404CF0554ACB2B942C11szxeml546mbxchi_-- From wesley.george@twcable.com Fri Jul 6 09:51:06 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@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 Cc: "behave@ietf.org" , "sunset4@ietf.org" Subject: Re: [sunset4] Last Call: (Common requirements for Carrier Grade NATs (CGNs)) to Best Current Practice X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list 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: sunset4@ietfa.amsl.com Delivered-To: sunset4@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: [sunset4] Last Call: (Common requirements for Carrier Grade NATs (CGNs)) to Best Current Practice X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list 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 cathy.zhou@huawei.com Sun Jul 8 23:14:25 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F88121F8675 for ; Sun, 8 Jul 2012 23:14:25 -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 eOr3oFHhrzgJ for ; Sun, 8 Jul 2012 23:14:24 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id AC36D21F8666 for ; Sun, 8 Jul 2012 23:14:24 -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 AHO93657; Mon, 09 Jul 2012 02:14:48 -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; Sun, 8 Jul 2012 23:14:17 -0700 Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 8 Jul 2012 23:14:16 -0700 Received: from SZXEML527-MBS.china.huawei.com ([169.254.6.143]) by szxeml408-hub.china.huawei.com ([10.82.67.95]) with mapi id 14.01.0323.003; Mon, 9 Jul 2012 14:14:11 +0800 From: "Zhouqian (Cathy)" To: "sunset4-chairs@tools.ietf.org" Thread-Topic: New Version Notification for draft-zhou-sunset4-scenarios-00.txt Thread-Index: AQHNXXPa0USsHsomA0SP0SdPCe2TkJcgdv/g Date: Mon, 9 Jul 2012 06:14:11 +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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "sunset4@ietf.org" Subject: [sunset4] FW: New Version Notification for draft-zhou-sunset4-scenarios-00.txt X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 06:14:25 -0000 RGVhciBjaGFpcnMsDQpXZSdkIGxpa2UgdG8gYXNrIGEgMTAgbWludXRlcyBzbG90IGZvciB0aGUg Zm9sbG93aW5nIGRvY3VtZW50Og0KaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv ZHJhZnQtemhvdS1zdW5zZXQ0LXNjZW5hcmlvcy0wMC50eHQNClRoYW5rcy4NCg0KQmVzdCBSZWdh cmRzLA0KQ2F0aHkgWmhvdQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSAN ClNlbnQ6IE1vbmRheSwgSnVseSAwOSwgMjAxMiA5OjQwIEFNDQpUbzogWmhvdXFpYW4gKENhdGh5 KQ0KQ2M6IFRpbmEgVFNPVQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk cmFmdC16aG91LXN1bnNldDQtc2NlbmFyaW9zLTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2Yg SS1ELCBkcmFmdC16aG91LXN1bnNldDQtc2NlbmFyaW9zLTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vz c2Z1bGx5IHN1Ym1pdHRlZCBieSBDYXRoeSBaaG91IGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJl cG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtemhvdS1zdW5zZXQ0LXNjZW5hcmlvcw0KUmV2 aXNpb246CSAwMA0KVGl0bGU6CQkgU2NlbmFyaW9zIG9mIElQdjQgc3Vuc2V0dGluZw0KQ3JlYXRp b24gZGF0ZToJIDIwMTItMDctMDkNCldHIElEOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVt YmVyIG9mIHBhZ2VzOiA2DQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzL2RyYWZ0LXpob3Utc3Vuc2V0NC1zY2VuYXJpb3MtMDAudHh0DQpTdGF0dXM6 ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtemhvdS1zdW5z ZXQ0LXNjZW5hcmlvcw0KSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC16aG91LXN1bnNldDQtc2NlbmFyaW9zLTAwDQoNCg0KQWJzdHJhY3Q6DQogICBUaGlz IGRvY3VtZW50IGRlc2NyaWJlcyBzY2VuYXJpb3MgYXQgc3Vic2NyaWJlciwgY2FycmllciBhbmQN CiAgIGVudGVycHJpc2Ugc2l0ZXMgZHVyaW5nIElQdjQgc3Vuc2V0dGluZy4gIEluIGVhY2ggc2l0 ZSwgdGhlcmUgbWF5IGJlDQogICBkaWZmZXJlbnQgcmVxdWlyZW1lbnRzIGFuZCBpc3N1ZXMuICBU aGUgYWltIG9mIHRoaXMgZG9jdW1lbnQgaXMgdG8NCiAgIHB1dCBmb3J3YXJkIHNvbWUgaXNzdWVz IGluIHRoZXNlIHNjZW5hcmlvcyBhbmQgdG8gaWRlbnRpZnkgd2hldGhlcg0KICAgZnVydGhlciBz cGVjaWZpY2F0aW9ucyBhcmUgbmVlZGVkIHRvIHNvbHZlIHRoZXNlIGlzc3VlcyB0byBmYWNpbGl0 YXRlDQogICBJUHY0IHN1bnNldHRpbmcuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0K DQpUaGUgSUVURiBTZWNyZXRhcmlhdA0K From wesley.george@twcable.com Mon Jul 9 08:03:14 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@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 Cc: "behave@ietf.org" , "ietf@ietf.org" , "sunset4@ietf.org" Subject: Re: [sunset4] Last Call: (Common requirements for Carrier Grade NATs (CGNs)) to Best Current Practice X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list 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 Mon Jul 9 08:08:25 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@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: [sunset4] Last Call: (Common requirements for Carrier Grade NATs (CGNs)) to Best Current Practice X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list 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 simon.perreault@viagenie.ca Mon Jul 9 10:50:57 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A68811E81B5 for ; Mon, 9 Jul 2012 10:50:57 -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 mZhwLcxQHtpA for ; Mon, 9 Jul 2012 10:50:57 -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 0186711E8159 for ; Mon, 9 Jul 2012 10:50:56 -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 A6B38415DA for ; Mon, 9 Jul 2012 13:51:20 -0400 (EDT) Message-ID: <4FFB1A18.3030204@viagenie.ca> Date: Mon, 09 Jul 2012 13:51:20 -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: "sunset4@ietf.org" References: <20120709174359.6813.42129.idtracker@ietfa.amsl.com> In-Reply-To: <20120709174359.6813.42129.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120709174359.6813.42129.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [sunset4] Fwd: New Version Notification for draft-perreault-sunset4-noipv4-00.txt X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 17:50:57 -0000 All, Here's a draft about a way to disable IPv4 using a new DHCPv6 option. The option means basically "there is no IPv4 on this network, don't even ask for it". There is also a stricter version of the option that means "oh and turn off any IPv4 function you may have, on any interface, even loopback". >:-] Any comments appreciated. We're also preemptively requesting a slot for this in Vancouver. :) Simon -------- Original Message -------- Subject: New Version Notification for draft-perreault-sunset4-noipv4-00.txt Date: Mon, 09 Jul 2012 10:43:59 -0700 From: internet-drafts@ietf.org To: simon.perreault@viagenie.ca CC: wesley.george@twcable.com, tina.tsou.zouting@huawei.com A new version of I-D, draft-perreault-sunset4-noipv4-00.txt has been successfully submitted by Simon Perreault and posted to the IETF repository. Filename: draft-perreault-sunset4-noipv4 Revision: 00 Title: Turning off IPv4 Using DHCPv6 Creation date: 2012-07-09 WG ID: Individual Submission Number of pages: 9 URL: http://www.ietf.org/internet-drafts/draft-perreault-sunset4-noipv4-00.txt Status: http://datatracker.ietf.org/doc/draft-perreault-sunset4-noipv4 Htmlized: http://tools.ietf.org/html/draft-perreault-sunset4-noipv4-00 Abstract: This memo defines a new DHCPv6 option for indicating to a dual-stack host or router that IPv4 is to be turned off. The IETF Secretariat From simon.perreault@viagenie.ca Mon Jul 9 12:34:07 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34DE711E81FC for ; Mon, 9 Jul 2012 12:34:07 -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 oXSp9EfIUmKj for ; Mon, 9 Jul 2012 12:34:06 -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 B23D911E8149 for ; Mon, 9 Jul 2012 12:34:06 -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 C8E8C412C4 for ; Mon, 9 Jul 2012 15:34:31 -0400 (EDT) Message-ID: <4FFB3247.7080400@viagenie.ca> Date: Mon, 09 Jul 2012 15:34:31 -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: "sunset4@ietf.org" References: <20120709193059.3014.95187.idtracker@ietfa.amsl.com> In-Reply-To: <20120709193059.3014.95187.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120709193059.3014.95187.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [sunset4] Fwd: New Version Notification for draft-perreault-sunset4-cgn-mib-00.txt X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 19:34:07 -0000 Sunsetters, Another -00 draft for sunset4, although there is nothing new here. It is simply an extract of draft-ietf-behave-nat-mib of items that apply to CGN. The rest of the draft-ietf-behave-nat-mib is generic to all kinds of NAT. So we have been asked to split the draft in two, keeping the generic parts in behave and moving the CGN-specific parts into sunset4. Simon -------- Original Message -------- Subject: New Version Notification for draft-perreault-sunset4-cgn-mib-00.txt Date: Mon, 09 Jul 2012 12:30:59 -0700 From: internet-drafts@ietf.org To: simon.perreault@viagenie.ca CC: ssenthil@cisco.com, tina.tsou.zouting@huawei.com A new version of I-D, draft-perreault-sunset4-cgn-mib-00.txt has been successfully submitted by Simon Perreault and posted to the IETF repository. Filename: draft-perreault-sunset4-cgn-mib Revision: 00 Title: Managed Objects for Carrier Grade NAT (CGN) Creation date: 2012-07-09 WG ID: Individual Submission Number of pages: 10 URL: http://www.ietf.org/internet-drafts/draft-perreault-sunset4-cgn-mib-00.txt Status: http://datatracker.ietf.org/doc/draft-perreault-sunset4-cgn-mib Htmlized: http://tools.ietf.org/html/draft-perreault-sunset4-cgn-mib-00 Abstract: This memo defines a portion of the Management Information Base (MIB) that may be used for monitoring of a device capable of Carrier Grade NAT function. The IETF Secretariat From wesley.george@twcable.com Tue Jul 10 04:02:52 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E76AC21F877A for ; Tue, 10 Jul 2012 04:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[AWL=-0.236, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gxoH2t3Oun3l for ; Tue, 10 Jul 2012 04:02:50 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 664B521F86A5 for ; Tue, 10 Jul 2012 04:02:50 -0700 (PDT) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.77,559,1336363200"; d="scan'208,217";a="390259394" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 10 Jul 2012 07:02:41 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Tue, 10 Jul 2012 07:03:17 -0400 From: "George, Wes" To: "sunset4@ietf.org" Date: Tue, 10 Jul 2012 07:03:02 -0400 Thread-Topic: Call for Agenda Items Thread-Index: Ac1ei4sYs7rPhVWkSp6foPne2J2Adg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_DCC302FAA9FE5F4BBA4DCAD4656937791745A1F85DPRVPEXVS03cor_" MIME-Version: 1.0 Subject: [sunset4] Call for Agenda Items X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 11:02:53 -0000 --_000_DCC302FAA9FE5F4BBA4DCAD4656937791745A1F85DPRVPEXVS03cor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All - sorry for the confusion and stuttering out of the gate with this WG. = We have been working with some of the WG chairs of related WGs and the ADs = to clarify the division of work among the different groups, as well as some= items in Sunset4's charter so that we could give clearer feedback regardin= g what was and was not in scope for this group. While your chairs have worked out an agreement with the IntArea ADs on some= minor wording tweaks to eliminate some contradictions and clarify things s= ignificantly, we don't know whether formal IESG approval will be needed, or= if the ADs can just ask the secretariat to make the change. We'll keep you= posted. But in the interest of making forward progress on setting up an agenda, her= e is some guidance. Every draft that is considered for adoption in this WG will need to answer = these questions: 1) describe the problem to be solved and show that there is widespread dema= nd for a solution 2) demonstrate that the problem can not be solved with existing technologie= s 3) provide a description of the proposed solution along with its impact on = current IPv4-only use and justification that it does not harm or delay the = deployment of IPv6 The authors of drafts to be considered should respond to the list with answ= ers to these questions. We need that before officially adding your draft to= the agenda. Your presentation should at least briefly cover these points a= s well. We have a 2 hour session on Monday @1300. Agenda: 13:00 - 13:05 Note well, administrivia, scribes, minutes 13:05 - 13:10 Agenda Bashing 13:10 - 13:25 WG Charter and Scope discussion 14:45 - 15:00 - summary/wrap-up This leaves ~70 minutes for presentations. We've seen messages to the list = with potential drafts, including: draft-dionne-sunset4-v4gapanalysis draft-tsou-stateless-nat44 draft-zhou-sunset4-scenarios draft-perreault-sunset4-noipv4 draft-perreault-sunset4-cgn-mib We're figuring on 10 minutes per draft, meaning that we have room for proba= bly 2 more drafts. If you think you'll need more, please explain why. Authors, even if you have already sent a message to the chairs asking for a= slot, you need to answer the questions above before you officially have a = slot. Thanks, Wes George (and Marc Blanchet, who is currently on vacation) ________________________________ 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. --_000_DCC302FAA9FE5F4BBA4DCAD4656937791745A1F85DPRVPEXVS03cor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All – sorry for the confusion and stuttering o= ut of the gate with this WG. We have been working with some of the WG chair= s of related WGs and the ADs to clarify the division of work among the diff= erent groups, as well as some items in Sunset4’s charter so that we could give clearer feedback regarding what was and was = not in scope for this group.

 

While your chairs have worked out an agreement with = the IntArea ADs on some minor wording tweaks to eliminate some contradictio= ns and clarify things significantly, we don’t know whether formal IES= G approval will be needed, or if the ADs can just ask the secretariat to make the change. We’ll keep you post= ed.

 

But in the interest of making forward progress on se= tting up an agenda, here is some guidance.

 

Every draft that is considered for adoption in this = WG will need to answer these questions:

1) describe the problem to be solved and show that t= here is widespread demand for a solution
2) demonstrate that the problem can not be solved with existing techno= logies
3) provide a description of the proposed solution along with its impact on = current IPv4-only use and justification that it does not harm or delay the = deployment of IPv6

 

The authors of drafts to be considered should respon= d to the list with answers to these questions. We need that before official= ly adding your draft to the agenda. Your presentation should at least brief= ly cover these points as well.

 

We have a 2 hour session on Monday @1300.

Agenda:

 

13:00 – 13:05 Note well, administrivia, scribe= s, minutes

13:05 – 13:10 Agenda Bashing

13:10 – 13:25 WG Charter and Scope discussion =

 

14:45 – 15:00 – summary/wrap-up

 

This leaves ~70 minutes for presentations. We’= ve seen messages to the list with potential drafts, including:

draft-dionne-sunset4-v4gapanalysis

draft-tso= u-stateless-nat44

draft-zhou-sunset4-scenarios

draft-perreault-sunset4-noipv4

draft-perreault-sunset4-cgn-mib

 

We’re figuring on 10 minutes per draft, meanin= g that we have room for probably 2 more drafts. If you think you’ll n= eed more, please explain why.

 

Authors, even if you have already sent a message to = the chairs asking for a slot, you need to answer the questions above before= you officially have a slot.

 

Thanks,

 

Wes George (and Marc Blanchet, who is currently on v= acation)


This E-mail and any of its a= ttachments may contain Time Warner Cable proprietary information, which is = privileged, confidential, or subject to copyright belonging to Time Warner = Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.
 --_000_DCC302FAA9FE5F4BBA4DCAD4656937791745A1F85DPRVPEXVS03cor_-- From Tina.Tsou.Zouting@huawei.com Tue Jul 10 19:46:21 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@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: [sunset4] Last Call: (Common requirements for Carrier Grade NATs (CGNs)) to Best Current Practice X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list 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 miyakawa@nttv6.jp Wed Jul 11 00:34:18 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@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: simon.perreault@viagenie.ca, behave@ietf.org, ietf@ietf.org, wesley.george@twcable.com, sunset4@ietf.org, miyakawa@nttv6.jp Subject: Re: [sunset4] [BEHAVE] Last Call: (Common requirements for Carrier Grade NATs (CGNs)) to Best Current Practice X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list 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 02:59:02 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 442F421F85F9 for ; Wed, 11 Jul 2012 02:59:02 -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 7PPu3OCaxQhu for ; Wed, 11 Jul 2012 02:59:01 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9E70821F8663 for ; Wed, 11 Jul 2012 02:59:01 -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 AHQ77595; Wed, 11 Jul 2012 05:59:31 -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; Wed, 11 Jul 2012 02:57:26 -0700 Received: from SZXEML431-HUB.china.huawei.com (10.72.61.39) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 11 Jul 2012 02:57:31 -0700 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.75]) by szxeml431-hub.china.huawei.com ([10.72.61.39]) with mapi id 14.01.0323.003; Wed, 11 Jul 2012 17:56:48 +0800 From: "Will Liu (Shucheng)" To: "sunset4@ietf.org" Thread-Topic: New Version Notification for draft-li-behave-nat444-test-00.txt Thread-Index: AQHNXdfAL8j28hZWeESjBzjnjQWiCpcg89lAgAFG31CAAZxzEA== Date: Wed, 11 Jul 2012 09:56:47 +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 Cc: "liuchunlin@jsptpd.com" , "Zhangzongjian \(Thomas\)" , "15306188213@189.cn" <15306188213@189.cn>, "15301588336@189.cn" <15301588336@189.cn> Subject: [sunset4] FW: New Version Notification for draft-li-behave-nat444-test-00.txt X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 09:59:02 -0000 SGkgLCANCg0KV2UgaGF2ZSBzdWJtaXR0ZWQgYSBuZXcgZHJhZnQgZW50aXRsZWQgIiBOQVQ0NCBU cmFuc2xhdGlvbiBUZXN0aW5nIGluIFd1eGkgQnJhbmNoIG9mIENoaW5hIFRlbGVjb20iLiBUaGUg aW50ZW50IG9mIHRoZSBkcmFmdCBpcyB0byBkZXNjcmliZXMgdGhlIHRlc3RpbmcgcmVzdWx0IG9m IENHTiBkZXZpY2UgaW4gcmVhbCBuZXR3b3JrIGluIFd1eGkgQnJhbmNoIG9mIENoaW5hIFRlbGVj b20sIGJ5IHByb3ZpZGluZyBhbiBvdmVydmlldyBvZiBzdXBwb3J0IHNpdHVhdGlvbiBvZiBDR04g Zm9yIGdldHRpbmcgYXBwbGljYXRpb25zIHRocm91Z2ggTkFULiBUaGlzIGRyYWZ0IHdhcyBmaXJz dGx5IHBvc3RlZCB0byBiZWhhdmUuIEhvd2V2ZXIsIGNoYWlycyBvZiBiZWhhdmUgYmVsaWV2ZSB0 aGF0IGl0J3MgbW9yZSBhcHByb3ByaWF0ZSB0byBiZSBkaXNjdXNzZWQgaGVyZSBzaW5jZSBpdCdz IGEgQ0dOIHJlbGF0ZWQgd29yay4NCg0KVGhlIGxhdGVzdCB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBh dDoNCjwgaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1saS1iZWhhdmUtbmF0NDQ0LXRlc3Qt MDAudHh0Pg0KDQpBbnkgY29tbWVudHMgd2lsbCBiZSBoaWdobHkgYXBwcmVjaWF0ZWQuDQoNClJl Z2FyZHMsDQpXaWxsIA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNl bnQ6IE1vbmRheSwgSnVseSAwOSwgMjAxMiA5OjM1IFBNDQpUbzogV2lsbCBMaXUgKFNodWNoZW5n KQ0KQ2M6IGxpdWNodW5saW5AanNwdHBkLmNvbTsgWmhhbmd6b25namlhbiAoVGhvbWFzKTsgMTUz MDYxODgyMTNAMTg5LmNuOyAxNTMwMTU4ODMzNkAxODkuY24NClN1YmplY3Q6IE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbGktYmVoYXZlLW5hdDQ0NC10ZXN0LTAwLnR4dA0KDQoN CkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1saS1iZWhhdmUtbmF0NDQ0LXRlc3QtMDAudHh0 DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFdpbGwgTGl1IGFuZCBwb3N0ZWQg dG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtbGktYmVoYXZlLW5h dDQ0NC10ZXN0DQpSZXZpc2lvbjoJIDAwDQpUaXRsZToJCSBOQVQ0NCBUcmFuc2xhdGlvbiBUZXN0 aW5nIGluIFd1eGkgQnJhbmNoIG9mIENoaW5hIFRlbGVjb20NCkNyZWF0aW9uIGRhdGU6CSAyMDEy LTA3LTA5DQpXRyBJRDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczog MzMNClVSTDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv ZHJhZnQtbGktYmVoYXZlLW5hdDQ0NC10ZXN0LTAwLnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRw Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWxpLWJlaGF2ZS1uYXQ0NDQtdGVzdA0K SHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1saS1iZWhh dmUtbmF0NDQ0LXRlc3QtMDANCg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3Jp YmVzIHRoZSB0ZXN0aW5nIHJlc3VsdCBvZiBDR04gZGV2aWNlIGluIFd1eGkNCiAgIEJyYW5jaCBv ZiBDaGluYSBUZWxlY29tLCBieSBwcm92aWRpbmcgYW4gb3ZlcnZpZXcgb2Ygc3RhdGUgYWJvdXQN CiAgIHN1cHBvcnRpbmcgYXBwbGljYXRpb25zIHRvIGFkYXB0IHRvIE5BVCBieSBDR04uICBUaGUg Q0dOIGRldmljZSBpcw0KICAgZnJvbSBIdWF3ZWkgYW5kIHRoZSB0ZXN0IGVudmlyb25tZW50IGlz IHJlYWwgbmV0d29yayBpbiBXdXhpIENoaW5hLg0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0K From simon.perreault@viagenie.ca Wed Jul 11 07:00:44 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@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: [sunset4] Last Call: (Common requirements for Carrier Grade NATs (CGNs)) to Best Current Practice X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list 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 wesley.george@twcable.com Wed Jul 11 07:23:26 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7593921F86CE for ; Wed, 11 Jul 2012 07:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.679 X-Spam-Level: X-Spam-Status: No, score=-0.679 tagged_above=-999 required=5 tests=[AWL=-0.215, 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 BhnVDmxaRguY for ; Wed, 11 Jul 2012 07:23:25 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 9C41A21F8691 for ; Wed, 11 Jul 2012 07:23:25 -0700 (PDT) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.77,567,1336363200"; d="scan'208";a="390907812" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 11 Jul 2012 10:23:47 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Wed, 11 Jul 2012 10:23:52 -0400 From: "George, Wes" To: "sunset4@ietf.org" Date: Wed, 11 Jul 2012 10:23:50 -0400 Thread-Topic: draft-li-behave-NAT444-Test and draft-tsou-stateless-nat44 Thread-Index: Ac1fcMoO82YK7HwnScqfG82fGbA0+Q== 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="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sunset4] FW: draft-li-behave-NAT444-Test and draft-tsou-stateless-nat44 X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 14:23:26 -0000 The answers to our questions on two drafts are below. Please review and com= ment on the content of the answers, either together or separately. I'd like= some discussion on the draft or the questions on-list before we get into t= he meeting. Thanks Wes George -----Original Message----- From: Will Liu (Shucheng) [mailto:liushucheng@huawei.com] Sent: Wednesday, July 11, 2012 5:42 AM To: George, Wes Cc: sunset4-chairs@tools.ietf.org Subject: Asking for two 10min slots Hi George, Thanks for your kindly reminding. Sorry for my carelessness. :D May I ask f= or 2 time slots for draft-Li-Behave-NAT444-Test-00 and draft-tsou-stateless= -nat44=1B$B!)=1B(BEach presentation would last for 10min and the presenter = will be Will Liu. Following are my answers to your three question for both drafts: Q: 1) describe the problem to be solved and show that there is widespread dema= nd for a solution 2) demonstrate that the problem can not be solved with existing technologie= s 3) provide a description of the proposed solution along with its impact on = current IPv4-only use and justification that it does not harm or delay the = deployment of IPv6 A: draft-Li-Behave-NAT444-Test-00 1) NAT444 is a common scenario in operators=1B$B!G=1B(B network. Operators= are worried whether applications will be affected when they pass though mu= lti-level NAT. This test document provides experiences for both operators a= nd researchers. 2) During testing, we find some problems such as QQ online Gaming doesn=1B$= B!G=1B(Bt permit two user with the same public IP address in same game room= . 3) This is a testing draft. Proposed solution is not related. draft-tsou-stateless-nat44-00 1) To let the NAT44 CGN simple, to reduce the cost of CGN. Different from = traditional NAT44: no per-session state on the CGN, no binding table, no pe= r-flow state to be maintained, zero log, high speed, easy to deploy hot bac= kup. 2) Traditional NAT44 CGN need per-session state on the CGN, binding table,= per-flow state to be maintained. These make the CGN expensive and difficul= t to achieve CGN hot backup. 3) Solve the exhaustion of IPv4 address when the network migrate to IPv6. = Because it is stateless, the ISPs don=1B$B!G=1B(Bt need too much cost to de= ploy it. It can also be implemented in dual-stack network(IPv4 traffic pass= through stateless NAT44 and IPv6 traffic pass by stateless NAT44), so the = network can migrate to IPv6 smoothly. Regards, Will -----Original Message----- From: George, Wes [mailto:wesley.george@twcable.com] Sent: Wednesday, July 11, 2012 12:48 PM To: Will Liu (Shucheng); sunset4-chairs@tools.ietf.org Subject: RE: Asking for a 10min slot Please see the message I sent to the list this AM. Thanks, Wes > -----Original Message----- > From: Will Liu (Shucheng) [mailto:liushucheng@huawei.com] > Sent: Tuesday, July 10, 2012 5:30 AM > To: sunset4-chairs@tools.ietf.org > Subject: Asking for a 10min slot > > Hi Chairs, > > I am writing to ask for a 10 min slot for a presentation for > draft-tsou- stateless-nat44. > Presenter name is Will Liu and length of presentation is 10 minutes. > Thanks. > > Have a nice day! > Will 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 dwing@cisco.com Wed Jul 11 09:43:37 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5847021F85F8 for ; Wed, 11 Jul 2012 09:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.473 X-Spam-Level: X-Spam-Status: No, score=-110.473 tagged_above=-999 required=5 tests=[AWL=0.126, 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 hN9qXY2rHh94 for ; Wed, 11 Jul 2012 09:43:36 -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 3C5F321F8619 for ; Wed, 11 Jul 2012 09:43:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=5325; q=dns/txt; s=iport; t=1342025047; x=1343234647; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=llFKMVsOT0GCWbR7T4SrZdhfeiydqPSKWABmydvOZsU=; b=AqT9oFCXFXtxtRvMlo9LUAgAx686uHT1UISUL+PP/Tz5j2BNL91OZMKJ fhnpC+TD8CdyTooewFnHDTqKOr/cmMy3txz0K9cZquUxSgAA4bujkKf9+ RVHkBLDy79jnc+JFC+J0G/Wn1Gpv4Oe5QBcnUnMtjgYo9h/+H2o5rbpEF o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAHys/U+rRDoH/2dsb2JhbABFhWeiWY8sgQeCIAEBAQMBAQEBBQoBDgEIRAQMBwEDAgkPAgQBAQIDCxgCAwIZDhUKCAEIAQEEARILEAeHZQUMnTONFAGTBgSBHYojAhiEP4EVA4hLhQWWCoFmgn+BPw X-IronPort-AV: E=Sophos;i="4.77,569,1336348800"; d="scan'208";a="49079712" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 11 Jul 2012 16:44:05 +0000 Received: from dwingWS ([10.21.75.66]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q6BGi50h029129; Wed, 11 Jul 2012 16:44:05 GMT From: "Dan Wing" To: "'George, Wes'" , , "'Will Liu \(Shucheng\)'" References: In-Reply-To: Date: Wed, 11 Jul 2012 09:44:05 -0700 Message-ID: <0a5501cd5f84$6271cf40$27556dc0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac1fcMoO82YK7HwnScqfG82fGbA0+QAEjyPw Content-Language: en-us Subject: Re: [sunset4] FW: draft-li-behave-NAT444-Test and draft-tsou-stateless-nat44 X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 16:43:37 -0000 > -----Original Message----- > From: sunset4-bounces@ietf.org [mailto:sunset4-bounces@ietf.org] On > Behalf Of George, Wes > Sent: Wednesday, July 11, 2012 7:24 AM > To: sunset4@ietf.org > Subject: [sunset4] FW: draft-li-behave-NAT444-Test and draft-tsou- > stateless-nat44 > > The answers to our questions on two drafts are below. Please review and > comment on the content of the answers, either together or separately. > I'd like some discussion on the draft or the questions on-list before > we get into the meeting. See below. > Thanks > > Wes George > > > -----Original Message----- > From: Will Liu (Shucheng) [mailto:liushucheng@huawei.com] > Sent: Wednesday, July 11, 2012 5:42 AM > To: George, Wes > Cc: sunset4-chairs@tools.ietf.org > Subject: Asking for two 10min slots > > Hi George, > > Thanks for your kindly reminding. Sorry for my carelessness. :D May I > ask for 2 time slots for draft-Li-Behave-NAT444-Test-00 and draft-tsou- > stateless-nat44$B!)(BEach presentation would last for 10min and the > presenter will be Will Liu. > > Following are my answers to your three question for both drafts: > Q: > 1) describe the problem to be solved and show that there is widespread > demand for a solution > 2) demonstrate that the problem can not be solved with existing > technologies > 3) provide a description of the proposed solution along with its impact > on current IPv4-only use and justification that it does not harm or > delay the deployment of IPv6 > > A: > draft-Li-Behave-NAT444-Test-00 > 1) NAT444 is a common scenario in operators$B!G(B network. Operators are > worried whether applications will be affected when they pass though > multi-level NAT. This test document provides experiences for both > operators and researchers. > 2) During testing, we find some problems such as QQ online Gaming > doesn$B!G(Bt permit two user with the same public IP address in same game > room. Other applications have a similar restriction. For example, Mohamed has done extensive testing with BitTorrent and described the precise slowdowns and the precise failures when two users are sharing the same IPv4 address, draft-boucadair-pcp-bittorrent. Cablelabs published results of some of their testing using a different mix of applications. I have previously raised objections to their testing methodology and results. Their document is draft-donley-nat444-impacts. > 3) This is a testing draft. Proposed solution is not related. > > draft-tsou-stateless-nat44-00 > 1) To let the NAT44 CGN simple, to reduce the cost of CGN. Different > from traditional NAT44: no per-session state on the CGN, no binding > table, no per-flow state to be maintained, zero log, high speed, easy > to deploy hot backup. > 2) Traditional NAT44 CGN need per-session state on the CGN, binding > table, per-flow state to be maintained. These make the CGN expensive > and difficult to achieve CGN hot backup. > 3) Solve the exhaustion of IPv4 address when the network migrate to > IPv6. Because it is stateless, the ISPs don$B!G(Bt need too much cost to > deploy it. This seems to be a MAP solution. But differs from MAP in that it uses an IPv4 network between the subscriber and the ISP's "stateless NAT44" device, whereas MAP uses an IPv6 network between the subscriber and the ISP's "MAP border relay" device. > It can also be implemented in dual-stack network(IPv4 > traffic pass through stateless NAT44 and IPv6 traffic pass by stateless > NAT44), so the network can migrate to IPv6 smoothly. Typo in that sentence? -d > Regards, > Will > > > -----Original Message----- > From: George, Wes [mailto:wesley.george@twcable.com] > Sent: Wednesday, July 11, 2012 12:48 PM > To: Will Liu (Shucheng); sunset4-chairs@tools.ietf.org > Subject: RE: Asking for a 10min slot > > Please see the message I sent to the list this AM. > > Thanks, > > Wes > > > -----Original Message----- > > From: Will Liu (Shucheng) [mailto:liushucheng@huawei.com] > > Sent: Tuesday, July 10, 2012 5:30 AM > > To: sunset4-chairs@tools.ietf.org > > Subject: Asking for a 10min slot > > > > Hi Chairs, > > > > I am writing to ask for a 10 min slot for a presentation for > > draft-tsou- stateless-nat44. > > Presenter name is Will Liu and length of presentation is 10 minutes. > > Thanks. > > > > Have a nice day! > > Will > > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject > to copyright belonging to Time Warner Cable. This E-mail is intended > solely for the use 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 dissemination, distribution, copying, or > action taken in relation to the contents of and attachments to this E- > mail is strictly prohibited and may be unlawful. If you have received > this E-mail in error, please notify the sender immediately and > permanently delete the original and any copy of this E-mail and any > printout. > _______________________________________________ > sunset4 mailing list > sunset4@ietf.org > https://www.ietf.org/mailman/listinfo/sunset4 From C.Donley@cablelabs.com Wed Jul 11 14:19:43 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3776711E80EA for ; Wed, 11 Jul 2012 14:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[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 u1WJrsnhEmMV for ; Wed, 11 Jul 2012 14:19:41 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 5A50311E810F for ; Wed, 11 Jul 2012 14:19:41 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id q6BLK75J023709 for ; Wed, 11 Jul 2012 15:20:07 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Wed, 11 Jul 2012 15:20:07 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Wed, 11 Jul 2012 15:20:07 -0600 From: Chris Donley To: "sunset4@ietf.org" Date: Wed, 11 Jul 2012 15:21:47 -0600 Thread-Topic: New Version Notification for draft-donley-behave-deterministic-cgn-04.txt Thread-Index: Ac1fqvG6fLixMu2NTJW4HQJVNxusHA== Message-ID: In-Reply-To: <20120711210254.20594.88768.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_004_CC2346E55B08Fcdonleycablelabscom_" MIME-Version: 1.0 X-Approved: ondar Subject: [sunset4] FW: New Version Notification for draft-donley-behave-deterministic-cgn-04.txt X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 21:19:43 -0000 --_004_CC2346E55B08Fcdonleycablelabscom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I would like to discuss deterministic-cgn in Vancouver. In answer to the three questions: 1) describe the problem to be solved and show that there is widespread demand for a solution =20 Abuse response in a Carrier Grade NAT environment requires Service Providers to be able to map a subscriber=B9s inside address with the addres= s used on the public Internet. Unfortunately, many Carrier Grade NAT abuse-response solutions require per-connection logging. Research indicates that such logging is not scalable to many residential broadband services. =20 CableLabs has been approached by a group of Internet Service Providers and international public safety organizations to identify a solution to this problem. In addition, we discussed this approach at the last two IETF meetings, and heard from ISPs that there is widespread demand for this solution. =20 2) demonstrate that the problem can not be solved with existing Technologies =20 The existing solutions =AD per-connection logging and bulk-port logging still pose an impact on ISPs and public safety officials for logging and searching. Our approach deterministically maps internal addresses to {external address + port range} in such a way as to be able to algorithmically calculate the mapping. Only inputs and configuration of the algorithm need to be logged. This approach reduces both logging volume and subscriber identification times while increasing subscriber privacy (i.e. by not logging activity). =20 3) provide a description of the proposed solution along with its impact on current IPv4-only use and justification that it does not harm or delay the deployment of IPv6 =20 The solution described in this document is applicable to Carrier Grade NAT transition technologies (e.g. NAT444, DS-Lite, and NAT64). The authors acknowledge that native IPv6 will offer subscribers a better experience than CGN. However, many CPE devices only support IPv4. Likewise, only approximately 4% of the top 1 million websites are available using IPv6. Accordingly, deterministic CGN should in no way be understood as making CGN a replacement for IPv6 service. The authors encourage device manufacturers to consider RFC 6540 and include IPv6 support. In the interim, however, CGN has already been deployed in some ISP networks. Deterministic CGN will provide ISPs with the ability to quickly respond to public safety requests without requiring excessive infrastructure, operations, and bandwidth to support per-connection logging. The latest update addresses each of these in the text. Chris --=20 Chris Donley CCIE, CISSP, SCiPM Director - Network Technologies CableLabs=AE 858 Coal Creek Circle Louisville, CO 80027 303-661-3480 (v) On 7/11/12 3:02 PM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-donley-behave-deterministic-cgn-04.txt >has been successfully submitted by Chris Donley and posted to the >IETF repository. > >Filename: draft-donley-behave-deterministic-cgn >Revision: 04 >Title: Deterministic Address Mapping to Reduce Logging in Carrier Grade >NAT Deployments >Creation date: 2012-07-11 >WG ID: Individual Submission >Number of pages: 14 >URL: =20 >http://www.ietf.org/internet-drafts/draft-donley-behave-deterministic-cgn- >04.txt >Status: =20 >http://datatracker.ietf.org/doc/draft-donley-behave-deterministic-cgn >Htmlized: =20 >http://tools.ietf.org/html/draft-donley-behave-deterministic-cgn-04 >Diff: =20 >http://tools.ietf.org/rfcdiff?url2=3Ddraft-donley-behave-deterministic-cgn= -0 >4 > >Abstract: > Abuse response in a Carrier Grade NAT environment requires Service > Providers to be able to map a subscriber's inside address with the > address used on the public Internet. Unfortunately, many Carrier > Grade NAT abuse-response solutions require per-connection logging. > Research indicates that such logging is not scalable to many > residential broadband services. This document suggests a way to > manage Carrier Grade NAT translations in such a way as to > significantly reduce the amount of logging required while providing > traceability for abuse response. While the authors acknowledge that > IPv6 is a preferred solution, Carrier Grade NAT is a reality in many > networks, and is needed in situations where either customer equipment > or Internet content only supports IPv4; this approach should in no > way slow the deployment of IPv6. > > > =20 > =20 > > >The IETF Secretariat --_004_CC2346E55B08Fcdonleycablelabscom_ Content-Type: application/xml; name="default.xml" Content-Description: default.xml Content-Disposition: attachment; filename="default.xml"; size=3222; creation-date="Wed, 11 Jul 2012 15:20:06 GMT"; modification-date="Wed, 11 Jul 2012 15:20:06 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQCb6HBP/AAAABwCAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbKyRy2rDMBBF 94X+g9C22HK6KKXYzqKPXR+L9AMGeWyL2CMhTULy9x07LpQSAoVuBNLMvffMqFwfxkHtMSbnqdKr vNAKyfrGUVfpz81Ldq9VYqAGBk9Y6SMmva6vr8rNMWBSoqZU6Z45PBiTbI8jpNwHJKm0Po7Aco2d CWC30KG5LYo7Yz0xEmc8eei6fMIWdgOr54M8n0hErtXjqW+KqjSEMDgLLKBmqpqzuohDuiDcU/OL LlvIclHO5ql3Id0sCe+ymugaVB8Q+Q1G4TAsQ+LP8xVIRov5ZeYz0b5tncXG290o68hn48XsTwCr /4n+zjTz39ZfAAAA//8DAFBLAwQUAAYACAAAACEApdan58AAAAA2AQAACwAAAF9yZWxzLy5yZWxz hI/PasMwDIfvhb2D0X1R0sMYJXYvpZBDL6N9AOEof2giG9sb69tPxwYKuwiEpO/3qT3+rov54ZTn IBaaqgbD4kM/y2jhdj2/f4LJhaSnJQhbeHCGo3vbtV+8UNGjPM0xG6VItjCVEg+I2U+8Uq5CZNHJ ENJKRds0YiR/p5FxX9cfmJ4Z4DZM0/UWUtc3YK6PqMn/s8MwzJ5PwX+vLOVFBG43lExp5GKhqC/j U72QqGWq1B7Qtbj51v0BAAD//wMAUEsDBBQABgAIAAAAIQBreZYWgwAAAIoAAAAcAAAAdGhlbWUv dGhlbWUvdGhlbWVNYW5hZ2VyLnhtbAzMTQrDIBBA4X2hd5DZN2O7KEVissuuu/YAQ5waQceg0p/b 1+XjgzfO3xTVm0sNWSycBw2KZc0uiLfwfCynG6jaSBzFLGzhxxXm6XgYybSNE99JyHNRfSPVkIWt td0g1rUr1SHvLN1euSRqPYtHV+jT9yniResrJgoCOP0BAAD//wMAUEsDBBQABgAIAAAAIQAhWqKE IQcAANsdAAAWAAAAdGhlbWUvdGhlbWUvdGhlbWUxLnhtbOxZT28bRRS/I/EdRnsvsRMnTaI6VezY DbRpo9gt6nG8O/ZOM7uzmhkn8Q21RyQkREEcqMSNAwIqtRKX8mkCRVCkfgXezOyud+Jxk5QAFTSH 1jv7e2/e+70/82evXD1KGDogQlKeNoP6e7UAkTTkEU1HzeB2v3tpNUBS4TTCjKekGUyIDK5uvPvO FbyuYpIQBPKpXMfNIFYqW19YkCEMY/kez0gK74ZcJFjBoxgtRAIfgt6ELSzWaisLCaZpgFKcgNpb wyENCeprlcFGobzD4DFVUg+ETPS0auJIGGy0X9cIOZFtJtABZs0A5on4YZ8cqQAxLBW8aAY18xcs bFxZwOu5EFNzZCtyXfOXy+UC0f6imVOMBuWk9W5j7fJWqd8AmJrFdTqddqde6jMAHIbgqbWlqrPR Xa23Cp0VkP05q7tdW641XHxF/9KMzWutVmt5LbfFKjUg+7Mxg1+trTQ2Fx28AVn88gy+0dpst1cc vAFZ/MoMvnt5baXh4g0oZjTdn0HrgHa7ufYSMuRs2wtfBfhqLYdPUZANZXbpKYY8VfNyLcH3uOgC QAMZVjRFapKRIQ4hi9uY0YGgegK8TnDljR0K5cyQngvJUNBMNYMPMgwVMdX38tl3L589Qcf3nx7f //H4wYPj+z9YRY7UNk5HVakX33z6x6OP0O9Pvn7x8HM/Xlbxv3z/8c8/feYHQvlMzXn+xeNfnz5+ /uUnv3370APfFHhQhfdpQiS6SQ7RHk/AMcOKazkZiPNJ9GNMqxKb6UjiFOtZPPo7KnbQNyeYYQ+u RVwG7whoHz7gtfE9x+BeLMYqj7fj2fU4cYA7nLMWF14Wruu5KjT3x+nIP7kYV3F7GB/45m7j1Ilv Z5xB36Q+le2YOGbuMpwqPCIpUUi/4/uEePi6S6nD6w4NBZd8qNBdilqYeinp04GTTVOhbZpAXCY+ AyHeDjc7d1CLM5/XW+TARUJVYOYxvk+YQ+M1PFY48ans44RVCb+BVewzsjcRYRXXkQoiPSKMo05E pPTJ3BLgbyXo16F1+MO+wyaJixSK7vt03sCcV5FbfL8d4yTzYXs0javY9+U+pChGu1z54DvcrRD9 DHHA6dxw36HECffp3eA2HTkmTRNEvxkLTyyvEe7kb2/ChpiYVgNN3enVCU1f1bgT6Nu54xfXuKFV Pv/qkcfuN7VlbwIJvprZPtGo5+FOtuc2FxF987vzFh6nuwQKYnaJetuc3zbn4D/fnOfV88W35GkX hgatt0x2o2223cncXfeQMtZTE0ZuSLPxlrD2RF0Y1HLmxEnKU1gWw09dyTCBgxsJbGSQ4OpDquJe jDPYtNcDrWQkc9UjiTIu4bBohr26NR42/soeNZf1IcR2DonVDo/s8JIeLs4apRpj1cgcaIuJlrSC s062dDlXCr69zmR1bdSZZ6sb00xTdGYrXdYUm0M5UF66BoMlm7CpQbAVApZX4Myvp4bDDmYk0rzb GBVhMVH4e0KUe20diXFEbIic4QqbdRO7IoVm/NPu2Rw5H5sla0Da6UaYtJifP2ckuVAwJRkET1YT S6u1xVJ02AzWlheXAxTirBkM4ZgLP5MMgib1NhCzEdwVhUrYrD21Fk2RTj1e82dVHW4u5hSMU8aZ kGoLy9jG0LzKQ8VSPZO1f3G5oZPtYhzwNJOzWbG0Cinyr1kBoXZDS4ZDEqpqsCsjmjv7mHdCPlZE 9OLoEA3YWOxhCD9wqv2JqITbClPQ+gGu1jTb5pXbW/NOU73QMjg7jlkW47xb6quZouIs3PST0gbz VDEPfPPabpw7vyu64i/KlWoa/89c0csBXB4sRToCIdzsCox0pTQDLlTMoQtlMQ27AtZ90zsgW+B6 Fl4D+XC/bP4X5ED/b2vO6jBlDWdAtUdHSFBYTlQsCNmFtmSy7xRl9XzpsSpZrshkVMVcmVmzB+SA sL7ugSu6BwcohlQ33SRvAwZ3Mv/c57yCBiO9R6nWm9PJyqXT1sA/vXGxxQxOndhL6Pwt+C9NLFf3 6epn5Y14sUZWHdEvprukRlEVzuK3tpZP9ZomnGUBrqy1tmPNeLy4XBgHUZz1GAbL/UwGV0BI/wPr HxUhsx8r9ILa53vQWxF8e7D8IcjqS7qrQQbpBml/DWDfYwdtMmlVltp856NZKxbrC96olvOeIFtb dpZ4n5PschPlTufU4kWSnTPscG3H5lINkT1ZojA0LM4hJjDmK1f1QxQf3INAb8GV/5jZT1MygydT B9muMNk14NEk/8mkXXBt1ukzjEaydI8MEY2OivNHyYQtIft5pNgiG7QW04lWCi75Dg2uYI7Xona1 LIUXTxcuJczM0LJLYXOX5lMAH8fyxq2PdoC3TdZ6rYurYIqlf4WyMxjvp8x78jkrZfag+MpAvQZl 6ujVlOVMAXmziQefNwWGo1fP9F9YdGymm5Td+BMAAP//AwBQSwMEFAAGAAgAAAAhAA3RkJ+2AAAA GwEAACcAAAB0aGVtZS90aGVtZS9fcmVscy90aGVtZU1hbmFnZXIueG1sLnJlbHOEj00KwjAUhPeC dwhvb9O6EJEm3YjQrdQDhOQ1DTY/JFHs7Q2uLAguh2G+mWm7l53JE2My3jFoqhoIOumVcZrBbbjs jkBSFk6J2TtksGCCjm837RVnkUsoTSYkUiguMZhyDidKk5zQilT5gK44o49W5CKjpkHIu9BI93V9 oPGbAXzFJL1iEHvVABmWUJr/s/04GolnLx8WXf5RQXPZhQUoosbM4CObqkwEylu6usTfAAAA//8D AFBLAQItABQABgAIAAAAIQCb6HBP/AAAABwCAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9U eXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAKXWp+fAAAAANgEAAAsAAAAAAAAAAAAAAAAALQEAAF9y ZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAGt5lhaDAAAAigAAABwAAAAAAAAAAAAAAAAAFgIAAHRo ZW1lL3RoZW1lL3RoZW1lTWFuYWdlci54bWxQSwECLQAUAAYACAAAACEAIVqihCEHAADbHQAAFgAA AAAAAAAAAAAAAADTAgAAdGhlbWUvdGhlbWUvdGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQAN0ZCf tgAAABsBAAAnAAAAAAAAAAAAAAAAACgKAAB0aGVtZS90aGVtZS9fcmVscy90aGVtZU1hbmFnZXIu eG1sLnJlbHNQSwUGAAAAAAUABQBdAQAAIwsAAAAA --_004_CC2346E55B08Fcdonleycablelabscom_ Content-Type: application/xml; name="default[1].xml" Content-Description: default[1].xml Content-Disposition: attachment; filename="default[1].xml"; size=3222; creation-date="Wed, 11 Jul 2012 15:20:06 GMT"; modification-date="Wed, 11 Jul 2012 15:20:06 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQCb6HBP/AAAABwCAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbKyRy2rDMBBF 94X+g9C22HK6KKXYzqKPXR+L9AMGeWyL2CMhTULy9x07LpQSAoVuBNLMvffMqFwfxkHtMSbnqdKr vNAKyfrGUVfpz81Ldq9VYqAGBk9Y6SMmva6vr8rNMWBSoqZU6Z45PBiTbI8jpNwHJKm0Po7Aco2d CWC30KG5LYo7Yz0xEmc8eei6fMIWdgOr54M8n0hErtXjqW+KqjSEMDgLLKBmqpqzuohDuiDcU/OL LlvIclHO5ql3Id0sCe+ymugaVB8Q+Q1G4TAsQ+LP8xVIRov5ZeYz0b5tncXG290o68hn48XsTwCr /4n+zjTz39ZfAAAA//8DAFBLAwQUAAYACAAAACEApdan58AAAAA2AQAACwAAAF9yZWxzLy5yZWxz hI/PasMwDIfvhb2D0X1R0sMYJXYvpZBDL6N9AOEof2giG9sb69tPxwYKuwiEpO/3qT3+rov54ZTn IBaaqgbD4kM/y2jhdj2/f4LJhaSnJQhbeHCGo3vbtV+8UNGjPM0xG6VItjCVEg+I2U+8Uq5CZNHJ ENJKRds0YiR/p5FxX9cfmJ4Z4DZM0/UWUtc3YK6PqMn/s8MwzJ5PwX+vLOVFBG43lExp5GKhqC/j U72QqGWq1B7Qtbj51v0BAAD//wMAUEsDBBQABgAIAAAAIQBreZYWgwAAAIoAAAAcAAAAdGhlbWUv dGhlbWUvdGhlbWVNYW5hZ2VyLnhtbAzMTQrDIBBA4X2hd5DZN2O7KEVissuuu/YAQ5waQceg0p/b 1+XjgzfO3xTVm0sNWSycBw2KZc0uiLfwfCynG6jaSBzFLGzhxxXm6XgYybSNE99JyHNRfSPVkIWt td0g1rUr1SHvLN1euSRqPYtHV+jT9yniResrJgoCOP0BAAD//wMAUEsDBBQABgAIAAAAIQAhWqKE IQcAANsdAAAWAAAAdGhlbWUvdGhlbWUvdGhlbWUxLnhtbOxZT28bRRS/I/EdRnsvsRMnTaI6VezY DbRpo9gt6nG8O/ZOM7uzmhkn8Q21RyQkREEcqMSNAwIqtRKX8mkCRVCkfgXezOyud+Jxk5QAFTSH 1jv7e2/e+70/82evXD1KGDogQlKeNoP6e7UAkTTkEU1HzeB2v3tpNUBS4TTCjKekGUyIDK5uvPvO FbyuYpIQBPKpXMfNIFYqW19YkCEMY/kez0gK74ZcJFjBoxgtRAIfgt6ELSzWaisLCaZpgFKcgNpb wyENCeprlcFGobzD4DFVUg+ETPS0auJIGGy0X9cIOZFtJtABZs0A5on4YZ8cqQAxLBW8aAY18xcs bFxZwOu5EFNzZCtyXfOXy+UC0f6imVOMBuWk9W5j7fJWqd8AmJrFdTqddqde6jMAHIbgqbWlqrPR Xa23Cp0VkP05q7tdW641XHxF/9KMzWutVmt5LbfFKjUg+7Mxg1+trTQ2Fx28AVn88gy+0dpst1cc vAFZ/MoMvnt5baXh4g0oZjTdn0HrgHa7ufYSMuRs2wtfBfhqLYdPUZANZXbpKYY8VfNyLcH3uOgC QAMZVjRFapKRIQ4hi9uY0YGgegK8TnDljR0K5cyQngvJUNBMNYMPMgwVMdX38tl3L589Qcf3nx7f //H4wYPj+z9YRY7UNk5HVakX33z6x6OP0O9Pvn7x8HM/Xlbxv3z/8c8/feYHQvlMzXn+xeNfnz5+ /uUnv3370APfFHhQhfdpQiS6SQ7RHk/AMcOKazkZiPNJ9GNMqxKb6UjiFOtZPPo7KnbQNyeYYQ+u RVwG7whoHz7gtfE9x+BeLMYqj7fj2fU4cYA7nLMWF14Wruu5KjT3x+nIP7kYV3F7GB/45m7j1Ilv Z5xB36Q+le2YOGbuMpwqPCIpUUi/4/uEePi6S6nD6w4NBZd8qNBdilqYeinp04GTTVOhbZpAXCY+ AyHeDjc7d1CLM5/XW+TARUJVYOYxvk+YQ+M1PFY48ans44RVCb+BVewzsjcRYRXXkQoiPSKMo05E pPTJ3BLgbyXo16F1+MO+wyaJixSK7vt03sCcV5FbfL8d4yTzYXs0javY9+U+pChGu1z54DvcrRD9 DHHA6dxw36HECffp3eA2HTkmTRNEvxkLTyyvEe7kb2/ChpiYVgNN3enVCU1f1bgT6Nu54xfXuKFV Pv/qkcfuN7VlbwIJvprZPtGo5+FOtuc2FxF987vzFh6nuwQKYnaJetuc3zbn4D/fnOfV88W35GkX hgatt0x2o2223cncXfeQMtZTE0ZuSLPxlrD2RF0Y1HLmxEnKU1gWw09dyTCBgxsJbGSQ4OpDquJe jDPYtNcDrWQkc9UjiTIu4bBohr26NR42/soeNZf1IcR2DonVDo/s8JIeLs4apRpj1cgcaIuJlrSC s062dDlXCr69zmR1bdSZZ6sb00xTdGYrXdYUm0M5UF66BoMlm7CpQbAVApZX4Myvp4bDDmYk0rzb GBVhMVH4e0KUe20diXFEbIic4QqbdRO7IoVm/NPu2Rw5H5sla0Da6UaYtJifP2ckuVAwJRkET1YT S6u1xVJ02AzWlheXAxTirBkM4ZgLP5MMgib1NhCzEdwVhUrYrD21Fk2RTj1e82dVHW4u5hSMU8aZ kGoLy9jG0LzKQ8VSPZO1f3G5oZPtYhzwNJOzWbG0Cinyr1kBoXZDS4ZDEqpqsCsjmjv7mHdCPlZE 9OLoEA3YWOxhCD9wqv2JqITbClPQ+gGu1jTb5pXbW/NOU73QMjg7jlkW47xb6quZouIs3PST0gbz VDEPfPPabpw7vyu64i/KlWoa/89c0csBXB4sRToCIdzsCox0pTQDLlTMoQtlMQ27AtZ90zsgW+B6 Fl4D+XC/bP4X5ED/b2vO6jBlDWdAtUdHSFBYTlQsCNmFtmSy7xRl9XzpsSpZrshkVMVcmVmzB+SA sL7ugSu6BwcohlQ33SRvAwZ3Mv/c57yCBiO9R6nWm9PJyqXT1sA/vXGxxQxOndhL6Pwt+C9NLFf3 6epn5Y14sUZWHdEvprukRlEVzuK3tpZP9ZomnGUBrqy1tmPNeLy4XBgHUZz1GAbL/UwGV0BI/wPr HxUhsx8r9ILa53vQWxF8e7D8IcjqS7qrQQbpBml/DWDfYwdtMmlVltp856NZKxbrC96olvOeIFtb dpZ4n5PschPlTufU4kWSnTPscG3H5lINkT1ZojA0LM4hJjDmK1f1QxQf3INAb8GV/5jZT1MygydT B9muMNk14NEk/8mkXXBt1ukzjEaydI8MEY2OivNHyYQtIft5pNgiG7QW04lWCi75Dg2uYI7Xona1 LIUXTxcuJczM0LJLYXOX5lMAH8fyxq2PdoC3TdZ6rYurYIqlf4WyMxjvp8x78jkrZfag+MpAvQZl 6ujVlOVMAXmziQefNwWGo1fP9F9YdGymm5Td+BMAAP//AwBQSwMEFAAGAAgAAAAhAA3RkJ+2AAAA GwEAACcAAAB0aGVtZS90aGVtZS9fcmVscy90aGVtZU1hbmFnZXIueG1sLnJlbHOEj00KwjAUhPeC dwhvb9O6EJEm3YjQrdQDhOQ1DTY/JFHs7Q2uLAguh2G+mWm7l53JE2My3jFoqhoIOumVcZrBbbjs jkBSFk6J2TtksGCCjm837RVnkUsoTSYkUiguMZhyDidKk5zQilT5gK44o49W5CKjpkHIu9BI93V9 oPGbAXzFJL1iEHvVABmWUJr/s/04GolnLx8WXf5RQXPZhQUoosbM4CObqkwEylu6usTfAAAA//8D AFBLAQItABQABgAIAAAAIQCb6HBP/AAAABwCAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9U eXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAKXWp+fAAAAANgEAAAsAAAAAAAAAAAAAAAAALQEAAF9y ZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAGt5lhaDAAAAigAAABwAAAAAAAAAAAAAAAAAFgIAAHRo ZW1lL3RoZW1lL3RoZW1lTWFuYWdlci54bWxQSwECLQAUAAYACAAAACEAIVqihCEHAADbHQAAFgAA AAAAAAAAAAAAAADTAgAAdGhlbWUvdGhlbWUvdGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQAN0ZCf tgAAABsBAAAnAAAAAAAAAAAAAAAAACgKAAB0aGVtZS90aGVtZS9fcmVscy90aGVtZU1hbmFnZXIu eG1sLnJlbHNQSwUGAAAAAAUABQBdAQAAIwsAAAAA --_004_CC2346E55B08Fcdonleycablelabscom_ Content-Type: application/xml; name="default[2].xml" Content-Description: default[2].xml Content-Disposition: attachment; filename="default[2].xml"; size=3222; creation-date="Wed, 11 Jul 2012 15:20:06 GMT"; modification-date="Wed, 11 Jul 2012 15:20:06 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQCb6HBP/AAAABwCAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbKyRy2rDMBBF 94X+g9C22HK6KKXYzqKPXR+L9AMGeWyL2CMhTULy9x07LpQSAoVuBNLMvffMqFwfxkHtMSbnqdKr vNAKyfrGUVfpz81Ldq9VYqAGBk9Y6SMmva6vr8rNMWBSoqZU6Z45PBiTbI8jpNwHJKm0Po7Aco2d CWC30KG5LYo7Yz0xEmc8eei6fMIWdgOr54M8n0hErtXjqW+KqjSEMDgLLKBmqpqzuohDuiDcU/OL LlvIclHO5ql3Id0sCe+ymugaVB8Q+Q1G4TAsQ+LP8xVIRov5ZeYz0b5tncXG290o68hn48XsTwCr /4n+zjTz39ZfAAAA//8DAFBLAwQUAAYACAAAACEApdan58AAAAA2AQAACwAAAF9yZWxzLy5yZWxz hI/PasMwDIfvhb2D0X1R0sMYJXYvpZBDL6N9AOEof2giG9sb69tPxwYKuwiEpO/3qT3+rov54ZTn IBaaqgbD4kM/y2jhdj2/f4LJhaSnJQhbeHCGo3vbtV+8UNGjPM0xG6VItjCVEg+I2U+8Uq5CZNHJ ENJKRds0YiR/p5FxX9cfmJ4Z4DZM0/UWUtc3YK6PqMn/s8MwzJ5PwX+vLOVFBG43lExp5GKhqC/j U72QqGWq1B7Qtbj51v0BAAD//wMAUEsDBBQABgAIAAAAIQBreZYWgwAAAIoAAAAcAAAAdGhlbWUv dGhlbWUvdGhlbWVNYW5hZ2VyLnhtbAzMTQrDIBBA4X2hd5DZN2O7KEVissuuu/YAQ5waQceg0p/b 1+XjgzfO3xTVm0sNWSycBw2KZc0uiLfwfCynG6jaSBzFLGzhxxXm6XgYybSNE99JyHNRfSPVkIWt td0g1rUr1SHvLN1euSRqPYtHV+jT9yniResrJgoCOP0BAAD//wMAUEsDBBQABgAIAAAAIQAhWqKE IQcAANsdAAAWAAAAdGhlbWUvdGhlbWUvdGhlbWUxLnhtbOxZT28bRRS/I/EdRnsvsRMnTaI6VezY DbRpo9gt6nG8O/ZOM7uzmhkn8Q21RyQkREEcqMSNAwIqtRKX8mkCRVCkfgXezOyud+Jxk5QAFTSH 1jv7e2/e+70/82evXD1KGDogQlKeNoP6e7UAkTTkEU1HzeB2v3tpNUBS4TTCjKekGUyIDK5uvPvO FbyuYpIQBPKpXMfNIFYqW19YkCEMY/kez0gK74ZcJFjBoxgtRAIfgt6ELSzWaisLCaZpgFKcgNpb wyENCeprlcFGobzD4DFVUg+ETPS0auJIGGy0X9cIOZFtJtABZs0A5on4YZ8cqQAxLBW8aAY18xcs bFxZwOu5EFNzZCtyXfOXy+UC0f6imVOMBuWk9W5j7fJWqd8AmJrFdTqddqde6jMAHIbgqbWlqrPR Xa23Cp0VkP05q7tdW641XHxF/9KMzWutVmt5LbfFKjUg+7Mxg1+trTQ2Fx28AVn88gy+0dpst1cc vAFZ/MoMvnt5baXh4g0oZjTdn0HrgHa7ufYSMuRs2wtfBfhqLYdPUZANZXbpKYY8VfNyLcH3uOgC QAMZVjRFapKRIQ4hi9uY0YGgegK8TnDljR0K5cyQngvJUNBMNYMPMgwVMdX38tl3L589Qcf3nx7f //H4wYPj+z9YRY7UNk5HVakX33z6x6OP0O9Pvn7x8HM/Xlbxv3z/8c8/feYHQvlMzXn+xeNfnz5+ /uUnv3370APfFHhQhfdpQiS6SQ7RHk/AMcOKazkZiPNJ9GNMqxKb6UjiFOtZPPo7KnbQNyeYYQ+u RVwG7whoHz7gtfE9x+BeLMYqj7fj2fU4cYA7nLMWF14Wruu5KjT3x+nIP7kYV3F7GB/45m7j1Ilv Z5xB36Q+le2YOGbuMpwqPCIpUUi/4/uEePi6S6nD6w4NBZd8qNBdilqYeinp04GTTVOhbZpAXCY+ AyHeDjc7d1CLM5/XW+TARUJVYOYxvk+YQ+M1PFY48ans44RVCb+BVewzsjcRYRXXkQoiPSKMo05E pPTJ3BLgbyXo16F1+MO+wyaJixSK7vt03sCcV5FbfL8d4yTzYXs0javY9+U+pChGu1z54DvcrRD9 DHHA6dxw36HECffp3eA2HTkmTRNEvxkLTyyvEe7kb2/ChpiYVgNN3enVCU1f1bgT6Nu54xfXuKFV Pv/qkcfuN7VlbwIJvprZPtGo5+FOtuc2FxF987vzFh6nuwQKYnaJetuc3zbn4D/fnOfV88W35GkX hgatt0x2o2223cncXfeQMtZTE0ZuSLPxlrD2RF0Y1HLmxEnKU1gWw09dyTCBgxsJbGSQ4OpDquJe jDPYtNcDrWQkc9UjiTIu4bBohr26NR42/soeNZf1IcR2DonVDo/s8JIeLs4apRpj1cgcaIuJlrSC s062dDlXCr69zmR1bdSZZ6sb00xTdGYrXdYUm0M5UF66BoMlm7CpQbAVApZX4Myvp4bDDmYk0rzb GBVhMVH4e0KUe20diXFEbIic4QqbdRO7IoVm/NPu2Rw5H5sla0Da6UaYtJifP2ckuVAwJRkET1YT S6u1xVJ02AzWlheXAxTirBkM4ZgLP5MMgib1NhCzEdwVhUrYrD21Fk2RTj1e82dVHW4u5hSMU8aZ kGoLy9jG0LzKQ8VSPZO1f3G5oZPtYhzwNJOzWbG0Cinyr1kBoXZDS4ZDEqpqsCsjmjv7mHdCPlZE 9OLoEA3YWOxhCD9wqv2JqITbClPQ+gGu1jTb5pXbW/NOU73QMjg7jlkW47xb6quZouIs3PST0gbz VDEPfPPabpw7vyu64i/KlWoa/89c0csBXB4sRToCIdzsCox0pTQDLlTMoQtlMQ27AtZ90zsgW+B6 Fl4D+XC/bP4X5ED/b2vO6jBlDWdAtUdHSFBYTlQsCNmFtmSy7xRl9XzpsSpZrshkVMVcmVmzB+SA sL7ugSu6BwcohlQ33SRvAwZ3Mv/c57yCBiO9R6nWm9PJyqXT1sA/vXGxxQxOndhL6Pwt+C9NLFf3 6epn5Y14sUZWHdEvprukRlEVzuK3tpZP9ZomnGUBrqy1tmPNeLy4XBgHUZz1GAbL/UwGV0BI/wPr HxUhsx8r9ILa53vQWxF8e7D8IcjqS7qrQQbpBml/DWDfYwdtMmlVltp856NZKxbrC96olvOeIFtb dpZ4n5PschPlTufU4kWSnTPscG3H5lINkT1ZojA0LM4hJjDmK1f1QxQf3INAb8GV/5jZT1MygydT B9muMNk14NEk/8mkXXBt1ukzjEaydI8MEY2OivNHyYQtIft5pNgiG7QW04lWCi75Dg2uYI7Xona1 LIUXTxcuJczM0LJLYXOX5lMAH8fyxq2PdoC3TdZ6rYurYIqlf4WyMxjvp8x78jkrZfag+MpAvQZl 6ujVlOVMAXmziQefNwWGo1fP9F9YdGymm5Td+BMAAP//AwBQSwMEFAAGAAgAAAAhAA3RkJ+2AAAA GwEAACcAAAB0aGVtZS90aGVtZS9fcmVscy90aGVtZU1hbmFnZXIueG1sLnJlbHOEj00KwjAUhPeC dwhvb9O6EJEm3YjQrdQDhOQ1DTY/JFHs7Q2uLAguh2G+mWm7l53JE2My3jFoqhoIOumVcZrBbbjs jkBSFk6J2TtksGCCjm837RVnkUsoTSYkUiguMZhyDidKk5zQilT5gK44o49W5CKjpkHIu9BI93V9 oPGbAXzFJL1iEHvVABmWUJr/s/04GolnLx8WXf5RQXPZhQUoosbM4CObqkwEylu6usTfAAAA//8D AFBLAQItABQABgAIAAAAIQCb6HBP/AAAABwCAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9U eXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAKXWp+fAAAAANgEAAAsAAAAAAAAAAAAAAAAALQEAAF9y ZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAGt5lhaDAAAAigAAABwAAAAAAAAAAAAAAAAAFgIAAHRo ZW1lL3RoZW1lL3RoZW1lTWFuYWdlci54bWxQSwECLQAUAAYACAAAACEAIVqihCEHAADbHQAAFgAA AAAAAAAAAAAAAADTAgAAdGhlbWUvdGhlbWUvdGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQAN0ZCf tgAAABsBAAAnAAAAAAAAAAAAAAAAACgKAAB0aGVtZS90aGVtZS9fcmVscy90aGVtZU1hbmFnZXIu eG1sLnJlbHNQSwUGAAAAAAUABQBdAQAAIwsAAAAA --_004_CC2346E55B08Fcdonleycablelabscom_-- From liushucheng@huawei.com Wed Jul 11 20:15:10 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03DD211E8100 for ; Wed, 11 Jul 2012 20:15:10 -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 QLFVb68kfYEF for ; Wed, 11 Jul 2012 20:15:09 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8D711E80B8 for ; Wed, 11 Jul 2012 20:15:09 -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 AHY33169; Wed, 11 Jul 2012 23:15:41 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 11 Jul 2012 20:13:28 -0700 Received: from SZXEML430-HUB.china.huawei.com (10.72.61.38) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 11 Jul 2012 20:13:33 -0700 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.75]) by szxeml430-hub.china.huawei.com ([10.72.61.38]) with mapi id 14.01.0323.003; Thu, 12 Jul 2012 11:13:29 +0800 From: "Will Liu (Shucheng)" To: "sunset4@ietf.org" Thread-Topic: [BEHAVE] comment on draft-li-behave-nat444-test-00, FTP active/passive Thread-Index: AQHNX3b4h7W5X72vskm19eILVZahlZck7XXggAAL3TA= Date: Thu, 12 Jul 2012 03:13:27 +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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [sunset4] FW: [BEHAVE] comment on draft-li-behave-nat444-test-00, FTP active/passive X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 03:15:10 -0000 I am forwarding the comments from behave for draft-li-behave-nat444-test-00 Regards, Will -----Original Message----- From: Will Liu (Shucheng)=20 Sent: Thursday, July 12, 2012 11:10 AM To: 'Dan Wing'; Zhangzongjian (Thomas); draft-li-behave-nat444-test@tools.i= etf.org; 15301588336@189.cn; 15306188213@189.cn; liuchunlin@jsptpd.com Cc: behave@ietf.org Subject: RE: [BEHAVE] comment on draft-li-behave-nat444-test-00, FTP active= /passive 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 cathy.zhou@huawei.com Thu Jul 12 04:56:43 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15F0821F8822 for ; Thu, 12 Jul 2012 04:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.395 X-Spam-Level: X-Spam-Status: No, score=-6.395 tagged_above=-999 required=5 tests=[AWL=0.203, 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 fSr5HS+19xL9 for ; Thu, 12 Jul 2012 04:56:40 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id BD7E921F879A for ; Thu, 12 Jul 2012 04:56:39 -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 AHR67420; Thu, 12 Jul 2012 07:57:12 -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; Thu, 12 Jul 2012 04:55:28 -0700 Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 12 Jul 2012 04:55:26 -0700 Received: from SZXEML527-MBS.china.huawei.com ([169.254.6.143]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.01.0323.003; Thu, 12 Jul 2012 19:55:18 +0800 From: "Zhouqian (Cathy)" To: "George, Wes" , "sunset4@ietf.org" Thread-Topic: Call for Agenda Items Thread-Index: Ac1ei4sYs7rPhVWkSp6foPne2J2AdgBRbBpw Date: Thu, 12 Jul 2012 11:55:17 +0000 Message-ID: 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.118] Content-Type: multipart/alternative; boundary="_000_A6A061BEE5DDC94A9692D9D81AF776DF2D471A33szxeml527mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [sunset4] Call for Agenda Items X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 11:56:43 -0000 --_000_A6A061BEE5DDC94A9692D9D81AF776DF2D471A33szxeml527mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I'd like to discuss this draft in Vancouver meeting: draft-zhou-sunset4-sce= narios-00. Here are the answers for chairs' questions: 1) describe the problem to be solved and show that there is widespread= demand for a solution This document describes scenarios at subscriber, carrier and enterprise sites during IPv4 sunsetting. It is not aiming at a solution. The purpose is to put forward some issues in these scenarios for WG disc= ussion and to identify whether solutions or specifications are needed. 2) demonstrate that the problem can not be solved with existing technologie= s At Subscriber Site, there are no existing technologies for DDNS if CGN is d= eployed. At Carrier site, draft-behave-lsn-requirements and RFC 6264 have defined CG= N requirement and a CGN model for IPv6 transition. However, there are some issues not mention= ed in these documents but some operators feel urgent to solve, e.g., traceback, ALG and etc. At enterprise site, some NAT related problems exist, e.g., if the enterpris= e network has no DNS server, how to announce the public address when the web server i= s required to provide this address. And there are no existing documents descr= ibing how do enterprise users record the NAT translation information. 3) provide a description of the proposed solution along with its impact on = current IPv4-only use and justification that it does not harm or delay the = deployment of IPv6 This document is not solution related. It only provides scenarios and probl= ems in IPv4-only environment. Best Regards, Cathy From: sunset4-bounces@ietf.org [mailto:sunset4-bounces@ietf.org] On Behalf = Of George, Wes Sent: Tuesday, July 10, 2012 7:03 PM To: sunset4@ietf.org Subject: [sunset4] Call for Agenda Items All - sorry for the confusion and stuttering out of the gate with this WG. = We have been working with some of the WG chairs of related WGs and the ADs = to clarify the division of work among the different groups, as well as some= items in Sunset4's charter so that we could give clearer feedback regardin= g what was and was not in scope for this group. While your chairs have worked out an agreement with the IntArea ADs on some= minor wording tweaks to eliminate some contradictions and clarify things s= ignificantly, we don't know whether formal IESG approval will be needed, or= if the ADs can just ask the secretariat to make the change. We'll keep you= posted. But in the interest of making forward progress on setting up an agenda, her= e is some guidance. Every draft that is considered for adoption in this WG will need to answer = these questions: 1) describe the problem to be solved and show that there is widespread dema= nd for a solution 2) demonstrate that the problem can not be solved with existing technologie= s 3) provide a description of the proposed solution along with its impact on = current IPv4-only use and justification that it does not harm or delay the = deployment of IPv6 The authors of drafts to be considered should respond to the list with answ= ers to these questions. We need that before officially adding your draft to= the agenda. Your presentation should at least briefly cover these points a= s well. We have a 2 hour session on Monday @1300. Agenda: 13:00 - 13:05 Note well, administrivia, scribes, minutes 13:05 - 13:10 Agenda Bashing 13:10 - 13:25 WG Charter and Scope discussion 14:45 - 15:00 - summary/wrap-up This leaves ~70 minutes for presentations. We've seen messages to the list = with potential drafts, including: draft-dionne-sunset4-v4gapanalysis draft-tsou-stateless-nat44 draft-zhou-sunset4-scenarios draft-perreault-sunset4-noipv4 draft-perreault-sunset4-cgn-mib We're figuring on 10 minutes per draft, meaning that we have room for proba= bly 2 more drafts. If you think you'll need more, please explain why. Authors, even if you have already sent a message to the chairs asking for a= slot, you need to answer the questions above before you officially have a = slot. Thanks, Wes George (and Marc Blanchet, who is currently on vacation) ________________________________ 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. --_000_A6A061BEE5DDC94A9692D9D81AF776DF2D471A33szxeml527mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

I’d like to discuss this = draft in Vancouver meeting: draft-zhou-sunset4-scenarios-00.

Here are the answers for chairs= ’ questions:

1= )   &= nbsp;  describe the problem to= be solved and show that there is widespread demand for a solution

Thi= s document describes scenarios at subscriber, carrier and=

   enterprise sites d= uring IPv4 sunsetting. It is not aiming at a solution.

   The purpose is to = put forward some issues in these scenarios for WG discussion

and= to identify whether solutions or specifications are needed.

2) demonstrate that the problem can not be solved with existing techno= logies

At = Subscriber Site, there are no existing technologies for DDNS if CGN is depl= oyed.

At = Carrier site, draft-behave-lsn-requirements and RFC 6264 have defined CGN r= equirement and

a C= GN model for IPv6 transition. However, there are some issues not mentioned = in these documents

but= some operators feel urgent to solve, e.g., traceback, ALG and etc.

At = enterprise site, some NAT related problems exist, e.g., if the enterprise n= etwork

has= no DNS server, how to announce the public address when the web server is

req= uired to provide this address. And there are no existing documents describi= ng how do enterprise

use= rs record the NAT translation information.

 

3) provide a description of the= proposed solution along with its impact on current IPv4-only use and justi= fication that it does not harm or delay the deployment of IPv6

Thi= s document is not solution related. It only provides scenarios and problems= in IPv4-only environment.

 

Bes= t Regards,

Cat= hy

From: sunset4-bounces@ietf.org [mailto:sunset4-bounces@ietf= .org] On Behalf Of George, Wes
Sent: Tuesday, July 10, 2012 7:03 PM
To: sunset4@ietf.org
Subject: [sunset4] Call for Agenda Items

 

All – sorry for the confu= sion and stuttering out of the gate with this WG. We have been working with= some of the WG chairs of related WGs and the ADs to clarify the division o= f work among the different groups, as well as some items in Sunset4’s charter so that we could give clearer fee= dback regarding what was and was not in scope for this group.

 

While your chairs have worked o= ut an agreement with the IntArea ADs on some minor wording tweaks to elimin= ate some contradictions and clarify things significantly, we don’t kn= ow whether formal IESG approval will be needed, or if the ADs can just ask the secretariat to make the change. We’ll= keep you posted.

 

But in the interest of making f= orward progress on setting up an agenda, here is some guidance.<= /span>

 

Every draft that is considered = for adoption in this WG will need to answer these questions:

1) describe the problem to be s= olved and show that there is widespread demand for a solution
2) demonstrate that the problem can not be solved with existing techno= logies
3) provide a description of the proposed solution along with its impact on = current IPv4-only use and justification that it does not harm or delay the = deployment of IPv6

 

The authors of drafts to be con= sidered should respond to the list with answers to these questions. We need= that before officially adding your draft to the agenda. Your presentation = should at least briefly cover these points as well.

 

We have a 2 hour session on Mon= day @1300.

Agenda:

 

13:00 – 13:05 Note well, = administrivia, scribes, minutes

13:05 – 13:10 Agenda Bash= ing

13:10 – 13:25 WG Charter = and Scope discussion

 

14:45 – 15:00 – sum= mary/wrap-up

 

This leaves ~70 minutes for pre= sentations. We’ve seen messages to the list with potential drafts, in= cluding:

draft-dionne-sunset4-v4gapanaly= sis

draft-tsou-stateless-nat44=

draft-zhou-sunset4-scenarios

draft-perreault-sunset4-noipv4<= o:p>

draft-perreault-sunset4-cgn-mib=

 

We’re figuring on 10 minu= tes per draft, meaning that we have room for probably 2 more drafts. If you= think you’ll need more, please explain why.

 

Authors, even if you have alrea= dy sent a message to the chairs asking for a slot, you need to answer the q= uestions above before you officially have a slot.

 

Thanks,

 

Wes George (and Marc Blanchet, = who is currently on vacation)

 

This E-mail and = any of its attachments may contain Time Warner Cable proprietary informatio= n, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use= of the individual or entity to which it is addressed. If you are not the i= ntended recipient of this E-mail, you are hereby notified that any dissemin= ation, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail= is strictly prohibited and may be unlawful. If you have received this E-ma= il in error, please notify the sender immediately and permanently delete th= e original and any copy of this E-mail and any printout.<= /span>

--_000_A6A061BEE5DDC94A9692D9D81AF776DF2D471A33szxeml527mbschi_-- From wesley.george@twcable.com Fri Jul 13 17:35:26 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4627C21F8692 for ; Fri, 13 Jul 2012 17:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.662 X-Spam-Level: X-Spam-Status: No, score=-0.662 tagged_above=-999 required=5 tests=[AWL=-0.199, 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 8+FvLF6dBfYi for ; Fri, 13 Jul 2012 17:35:25 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 20DDC21F8680 for ; Fri, 13 Jul 2012 17:35:25 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.77,583,1336363200"; d="scan'208";a="392383236" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 13 Jul 2012 20:35:48 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Fri, 13 Jul 2012 20:36:02 -0400 From: "George, Wes" To: "sunset4@ietf.org" Date: Fri, 13 Jul 2012 20:36:01 -0400 Thread-Topic: draft-li-behave-NAT444-Test Thread-Index: Ac1hDp5Z//h2ngVgTraeI8zNeC2PZg== 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 Cc: "liushucheng@huawei.com" Subject: [sunset4] draft-li-behave-NAT444-Test X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 00:35:26 -0000 I have some comments below on this draft. > From: Will Liu (Shucheng) [mailto:liushucheng@huawei.com] > Sent: Wednesday, July 11, 2012 5:42 AM > To: George, Wes > Cc: sunset4-chairs@tools.ietf.org > Subject: Asking for two 10min slots > > > Following are my answers to your three question for both drafts: > Q: > 1) describe the problem to be solved and show that there is widespread > demand for a solution > 2) demonstrate that the problem can not be solved with existing > technologies > 3) provide a description of the proposed solution along with its impact > on current IPv4-only use and justification that it does not harm or > delay the deployment of IPv6 > > A: > draft-Li-Behave-NAT444-Test-00 > 1) NAT444 is a common scenario in operators' network. Operators are > worried whether applications will be affected when they pass though > multi-level NAT. This test document provides experiences for both > operators and researchers. > 2) During testing, we find some problems such as QQ online Gaming > doesn't permit two user with the same public IP address in same game > room. > 3) This is a testing draft. Proposed solution is not related. > [WEG] Originally, I tried to separate my comments into comments as an indiv= idual and comments as a chair, but I'm having trouble doing so. Therefore I= 'll just present my feedback with the caveat that my personal opinions are = coloring my guidance and response, and hope that my comments are helpful. T= he last few sentences regarding whether we discuss this draft in Vancouver = are definitely spoken as Sunset4 co-chair. In its current form, I'm not certain that this draft has a lot of value as = a WG draft, whether for sunset4 or otherwise. It's already well-known that = NAT, especially when it is NAT444 will break certain applications and this = requires either an ALG or for the maintainer of that application to make ch= anges to their behavior so that it works properly through NAT. This draft h= as only one failed test case, and as others have pointed out, it's a known = address-sharing problem based on faulty assumptions about 1:1 mapping betwe= en end users and their IP addresses, rather than a problem specific to CGN'= s implementation. Therefore it cannot be solved by changes to CGN, nor "fix= ed" by IETF action. We want to continue to educate web and application prov= iders on this problem, but I think that has been well-covered by existing I= ETF work such that it doesn't justify another draft. IETF drafts, due to the time that they take to get to published state, and = the fact that they cannot be updated after publishing, do not lend themselv= es well to publishing something like test results of this nature, because t= est results are a snapshot in time. As soon as the test results are publish= ed, (hopefully) the problems identified get resolved, and the results get o= utdated. There is also a concern about the choices of the sites/application= s to test - they may be very popular at the time when the test was undertak= en, but their popularity may have waned to the point where the test is now = irrelevant. Unless the test results highlight an overall problem with a cer= tain class of site or application, or a certain common behavior that must b= e changed, they are relevant only if one knows the specific details of the = implementation of the application or site under test, and only if that impl= ementation does not undergo changes after publishing, either to fix brokenn= ess, or sometimes to break something that was previously working. These sor= ts of specific problems are best addressed directly with the site or applic= ation maintainer. IETF focuses on more widely applicable problems, such as = whether a new ALG should be standardized for a given class of application t= hat is broken, or if we should be providing updated guidance to application= and web providers to ensure that more applications work through CGN. Sunset4, and IETF as a whole, has a bit of a love/hate relationship with CG= N and NAT444. It's a necessary evil to preserve IPv4 functionality until IP= v6 is fully deployed. However, the message has been clear- use it only as = little as necessary, deploy IPv6, and be ready for things to break. Drafts = that give a false sense of security (all test cases passed except for one) = of how well CGN works are probably not in keeping with this message, especi= ally if they in no way mention that IPv4 + CGN is a temporary solution, and= that IPv6 is the long-term resolution. This draft is also too specific. It is discussing test results for one vend= or's CGN solution, and since there is little in the way of standards for im= plementing CGN, that may not be indicative of general CGN performance. This= is likely more appropriate to be published as a use case/test results whit= epaper on said vendor's website rather than via IETF. It is also very geogr= aphically specific given its focus on a specific region of a specific count= ry and mostly country/language-specific content and applications. While tha= t may be useful for those in that region, it limits the utility and relevan= ce of the test results for the wider IETF audience. In addition, it may lea= d to confusion by causing the reader to draw a conclusion that the results = will be indicative of the experience in other applications with other sites= , users, locations, etc. In truth, I think that the best message we can sen= d about CGN is "do your own testing on the applications that are important = to you and your customers, your mileage may vary significantly." It may be appropriate to pursue publishing this draft via independent submi= ssion, but I would need to hear strong support from the WG before adding it= to the agenda to be discussed further in Vancouver. 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 wesley.george@twcable.com Fri Jul 13 17:35:38 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21DA421F8680 for ; Fri, 13 Jul 2012 17:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.348 X-Spam-Level: X-Spam-Status: No, score=-0.348 tagged_above=-999 required=5 tests=[AWL=-0.485, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=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 FX0eCtcGJ0yJ for ; Fri, 13 Jul 2012 17:35:37 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id D855821F869A for ; Fri, 13 Jul 2012 17:35:36 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.77,583,1336363200"; d="scan'208";a="392383287" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 13 Jul 2012 20:36:00 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Fri, 13 Jul 2012 20:36:14 -0400 From: "George, Wes" To: "sunset4@ietf.org" Date: Fri, 13 Jul 2012 20:36:13 -0400 Thread-Topic: [sunset4] Call for Agenda Items Thread-Index: AQHNX3UBF1wJFlX750itn5Ek6PynUJckMxRAgABmH4CAAhS6gIAACZiAgABowoCAAEKa8A== Message-ID: References: <97A9B2B8-B1D5-4BAE-88C6-A99911EFEB4B@cisco.com> <20120713091447.8C16.8FE1F57E@jpix.ad.jp> <1F4ED938D73A4242BBBB1E7DD492EA0C1672A7E488@PMBX03.gsm1900.org> In-Reply-To: <1F4ED938D73A4242BBBB1E7DD492EA0C1672A7E488@PMBX03.gsm1900.org> 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 Subject: [sunset4] FW: Call for Agenda Items X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 00:35:38 -0000 Folks, the authors of 464xlat have requested that we consider their draft. = We're getting feedback that it's not a good fit in v6ops, and may be more a= ppropriate here. Please review and comment. The answers to our questions ar= e below, and are a good example of what we're looking for in terms of justi= fication. http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-05 Thanks, Wes -----Original Message----- From: Byrne, Cameron [mailto:Cameron.Byrne@T-Mobile.com] Sent: Friday, July 13, 2012 8:46 AM To: Fred Baker (fred); MAWATARI Masataka Cc: Marc Blanchet; George, Wes; joelja@bogus.com jaeggli; Ron Bonica; Ron B= onica; draft-ietf-v6ops-464xlat@tools.ietf.org; Ralph Droms Subject: RE: [sunset4] Call for Agenda Items 1) describe the problem to be solved and show that there is widespread dema= nd for a solution Problem =3D Fast growing edge networks require IPv4 service but IPv4 addres= ses are not available. IPv6-only service, including in combination with NA= T64/DNS64, is not a sufficient consumer offering since many applications (i= ncluding Skype) require IPv4 because they use IPv4 literals in their signal= ing or make IPv4-only socket calls. Thus, these applications require IPv4. = Our approximation is that 15% of application in the Android market require= IPv4 and do not work without it. Further description of why IPv6-only is not sufficient here http://tools.ie= tf.org/html/rfc6586 We believe the list traffic on this topic has shown widespread demand (T-Mo= bile USA, T-Mobile CZ, Rogers, TW Cable, BT, and representatives from other= service providers have noted on-list that this solution has value ... and = Android open source implementation is available and a commercial solution f= rom NEC) 2) demonstrate that the problem cannot be solved with existing technologies There is no available solution today, aside from the implementations of 464= XLAT, that allow an Android phone with an IPv6-only connection (with or wit= hout NAT64/DNS64) to make a Skype call or stream a Netflix movie. MAP solutions are in an adjacent space but are not acceptable for the follo= wing reasons. First, they require static port mapping. The static port mapping is not as= efficient as stateful dynamic NAT, especially given that port overloading = can allows 1 IPv4 address to source 100s of thousands of NAT64 connections.= For example, how many IPv4 addresses would it take to launch a new LTE se= rvice for 20 Million customers? At 1024 ports per customer? ... those addr= ess are not feasible to get without great expense with a MAP static mapping= . Second, it is not possible for an existing service provider, who by RIR pol= icy is required to be at least 80% deployed from their IPv4 reserves ... to= launch MAP. Meaning, if I have the vast majority of my addresses deployed= , it would not possible to easily move my deployed addresses into a MAP poo= l. This is especially the case for operators that already have stateful C= GN, moving to less address efficient MAP is not feasible with limited addre= sses. Finally, MAP requires DHCPv6. This is not available in 3GPP networks (GSM = / UMTS / LTE ) "Stateful DHCPv6-based address configuration [RFC3315] is not supported by 3GPP specifications." http://tools.ietf.org/html/rfc6459 3) provide a description of the proposed solution along with its impact on = current IPv4-only use and justification that it does not harm or delay the = deployment of IPv6 First, IPv6 access networks are a pre-requisite for the 464XLAT architectur= e, the architecture is explicitly made to enhance and expedite the effectiv= eness of IPv6-only networks. Also, from a network provider perspective, tr= anslation traffic cost more to operate, so the SP will be incented to encou= rage IPv6 native traffic. Description from the abstract: This document describes an architecture (464XLAT) for providing limited IPv4 connectivity across an IPv6-only network by combining existing and well-known stateful protocol translation RFC 6146 in the core and stateless protocol translation RFC 6145 at the edge. 464XLAT is a simple and scalable technique to quickly deploy limited IPv4 access service to IPv6-only edge networks without encapsulation. 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 wesley.george@twcable.com Fri Jul 13 17:35:44 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79FA421F8692 for ; Fri, 13 Jul 2012 17:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.115 X-Spam-Level: X-Spam-Status: No, score=-1.115 tagged_above=-999 required=5 tests=[AWL=0.348, 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 xp0rr8POthjz for ; Fri, 13 Jul 2012 17:35:43 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id A2BCC21F8680 for ; Fri, 13 Jul 2012 17:35:43 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.77,583,1336363200"; d="scan'208";a="409734804" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 13 Jul 2012 20:36:02 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Fri, 13 Jul 2012 20:36:11 -0400 From: "George, Wes" To: Dan Wing , "sunset4@ietf.org" , "'Will Liu (Shucheng)'" Date: Fri, 13 Jul 2012 20:36:10 -0400 Thread-Topic: draft-tsou-stateless-nat44 Thread-Index: Ac1hEHgD9fg1lWZuQdqYd+8o14pBMQ== 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 Subject: Re: [sunset4] draft-tsou-stateless-nat44 X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 00:35:44 -0000 > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Wednesday, July 11, 2012 12:44 PM > To: George, Wes; sunset4@ietf.org; 'Will Liu (Shucheng)' > Subject: RE: [sunset4] FW: draft-li-behave-NAT444-Test and draft-tsou- > stateless-nat44 > > This seems to be a MAP solution. But differs from MAP in that it uses > an IPv4 network between the subscriber and the ISP's "stateless NAT44" > device, whereas MAP uses an IPv6 network between the subscriber and the > ISP's "MAP border relay" device. [WEG] The chief criticism leveled at IPv4-only NAT solutions is that they d= o nothing to encourage IPv6 deployment, and instead function as IPv4 life-s= upport by allowing carriers to delay deployment of IPv6. The authors will h= ave a significant burden of justification as to why this is better than MAP= in that it doesn't push the implementer to deploy IPv6 on the network (or = at least allow the use of IPv6 as transport). Also, there are already multi= ple competing stateless solutions. I'd rather not add another without a ver= y good statement of what problem it's solving that the existing ones do not= . That's actually the reason for question #2 - "existing technologies" also= refers to alternate solutions to the same problem that are still in draft,= not just existing running code. > > > It can also be implemented in dual-stack network(IPv4 traffic pass > > through stateless NAT44 and IPv6 traffic pass by stateless NAT44), so > > the network can migrate to IPv6 smoothly. > > Typo in that sentence? [WEG] excepting the typo (bypass vs pass by), the draft should say this, an= d in fact should probably say it in stronger terms - "a network using this = NAT SHOULD deploy IPv6, so that all supporting devices and content can bypa= ss the NAT and maintain end-to-end connectivity" or some similar. This is a= drum we need to beat in every draft focused on an IPv4-only solution based= on the way that our charter is written and IETF's overall opinion about IP= V4 life-extension technologies. > > -d Thanks, Wes George, speaking as sunset4 co-chair. 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 wesley.george@twcable.com Fri Jul 13 17:36:01 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5548C21F8692 for ; Fri, 13 Jul 2012 17:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2XouIbb2TYH for ; Fri, 13 Jul 2012 17:35:58 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id DF90521F8680 for ; Fri, 13 Jul 2012 17:35:57 -0700 (PDT) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.77,583,1336363200"; d="scan'208,217";a="409734825" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 13 Jul 2012 20:36:09 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Fri, 13 Jul 2012 20:36:19 -0400 From: "George, Wes" To: "sunset4@ietf.org" Date: Fri, 13 Jul 2012 20:36:19 -0400 Thread-Topic: dionne-sunset4-v4gapanalysis and zhou-sunset4-scenarios Thread-Index: Ac1hKxAcWfWmmTdjRmmVaElVSCaLcA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_DCC302FAA9FE5F4BBA4DCAD4656937791745D3ADF9PRVPEXVS03cor_" MIME-Version: 1.0 Subject: [sunset4] dionne-sunset4-v4gapanalysis and zhou-sunset4-scenarios X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 00:36:01 -0000 --_000_DCC302FAA9FE5F4BBA4DCAD4656937791745D3ADF9PRVPEXVS03cor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Some comments on the two referenced drafts... I put them both in the same email, because I think that the scenarios and g= ap analysis are closely related, even if the current drafts may not necessa= rily be today. I think that we have two ways to go with this, either we have two drafts th= at are separate and interlinked, one that discusses scenarios and the other= that covers the gaps in those scenarios that are necessary for IPv4 sunset= , or one combined document that briefly sets up a scenario, and then discusse= s the gaps associated with the scenario. It's possible that the decision as= to which way this goes is related to whether there is a lot of commonality= in the gaps, where they apply to multiple scenarios vs being specific to a= given scenario. I'm open to opinions, but I'd like to get some discussion started on that, = either on list or during the meeting. That said - I don't think that the current scenario draft really is coverin= g the scenarios around IPv4 sunset. It actually looks like it is more about= CGN scenarios, and common problems in CGN. I would like to see us those se= parated, because they really are a separate set of problems to solve. One o= f the things that we need to be clear on when looking at work in this WG is= that IPv4 CGN !=3D IPv4 sunset. CGN is a bridge to get us through the poin= t where we must maintain support for legacy IPv4 now that addresses have ex= hausted, but in fact one of the scenarios for IPv4 sunset will be how to *t= urn off* the CGN IPv4 service, either all at once or in phases as a part of= an orderly shutdown of IPv4 on a given network. As with my comments on draft-li-behave-nat444-test, if we are going to put = together a list of scenarios/gaps/problems for CGN, we need to be very clea= rly focused on the things that are both common to a generic type of applica= tion/traffic/protocol rather than a specific site/application, and that can= be fixed either via BCP recommendations or standardizing CGN work (ALG or = implementation guidance). In other words, we need to be able to articulate = a problem for IETF to solve, rather than a problem for an individual implem= enter to solve. Further, we need to be thinking about whether the scenario = and problems are applicable to IPv4 NAT (like NAT44/NAT444) only, or wheth= er it's more generic to NAT and address sharing (including things like DSLi= te, NAT64, etc). If it's not specific to IPv4, it may be a better candidate= for BEHAVE, since they have already written multiple drafts covering BCP a= nd requirements for applications to function properly through generic NATs.= That work would need to serve as a starting point, where the authors would= need to identify specific gaps and needs requiring us to bolster what's al= ready there, but we're not necessarily chartered to do it if it's not a pro= blem specific to IPv4. Thanks, Wes George, speaking mostly as Sunset4 co-chair ________________________________ 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. --_000_DCC302FAA9FE5F4BBA4DCAD4656937791745D3ADF9PRVPEXVS03cor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Some comments on the two referenced drafts…

 

I put them both in the same email, because I think t= hat the scenarios and gap analysis are closely related, even if the current= drafts may not necessarily be today.

I think that we have two ways to go with this, eithe= r we have two drafts that are separate and interlinked, one that discusses = scenarios and the other that covers the gaps in those scenarios that are ne= cessary for IPv4 sunset,

or one combined document that briefly sets up a scen= ario, and then discusses the gaps associated with the scenario. It’s = possible that the decision as to which way this goes is related to whether = there is a lot of commonality in the gaps, where they apply to multiple scenarios vs being specific to a given scenar= io.

I’m open to opinions, but I’d like to ge= t some discussion started on that, either on list or during the meeting.

 

That said – I don’t think that the curre= nt scenario draft really is covering the scenarios around IPv4 sunset. It a= ctually looks like it is more about CGN scenarios, and common problems in C= GN. I would like to see us those separated, because they really are a separate set of problems to solve. One of the things tha= t we need to be clear on when looking at work in this WG is that IPv4 CGN != =3D IPv4 sunset. CGN is a bridge to get us through the point where we must = maintain support for legacy IPv4 now that addresses have exhausted, but in fact one of the scenarios for IPv4 s= unset will be how to *turn off* the CGN IPv4 service, either all at = once or in phases as a part of an orderly shutdown of IPv4 on a given netwo= rk.

 

As with my comments on draft-li-behave-nat444-test, = if we are going to put together a list of scenarios/gaps/problems for CGN, = we need to be very clearly focused on the things that are both common to a = generic type of application/traffic/protocol rather than a specific site/application, and that can be fixed either via = BCP recommendations or standardizing CGN work (ALG or implementation guidan= ce). In other words, we need to be able to articulate a problem for IETF to= solve, rather than a problem for an individual implementer to solve. Further, we need to be thinking about = whether the scenario and problems are applicable to IPv4 NAT  (like NA= T44/NAT444) only, or whether it’s more generic to NAT and address sha= ring (including things like DSLite, NAT64, etc). If it’s not specific to IPv4, it may be a better candidate for= BEHAVE, since they have already written multiple drafts covering BCP and r= equirements for applications to function properly through generic NATs. Tha= t work would need to serve as a starting point, where the authors would need to identify specific gaps and needs re= quiring us to bolster what’s already there, but we’re not neces= sarily chartered to do it if it’s not a problem specific to IPv4.

 

Thanks,

 

Wes George, speaking mostly as Sunset4 co-chair=


This E-mail and any of its a= ttachments may contain Time Warner Cable proprietary information, which is = privileged, confidential, or subject to copyright belonging to Time Warner = Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.
 --_000_DCC302FAA9FE5F4BBA4DCAD4656937791745D3ADF9PRVPEXVS03cor_-- From joelja@bogus.com Fri Jul 13 19:15:10 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF0721F85C0 for ; Fri, 13 Jul 2012 19:15:10 -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_13=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 AYjmKOJqvdA3 for ; Fri, 13 Jul 2012 19:15:09 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id A0E3221F85AD for ; Fri, 13 Jul 2012 19:15:09 -0700 (PDT) Received: from joels-MacBook-Air.local (adsl-76-199-100-31.dsl.pltn13.sbcglobal.net [76.199.100.31]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q6E2FkuK079804 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sat, 14 Jul 2012 02:15:46 GMT (envelope-from joelja@bogus.com) Message-ID: <5000D64C.4080004@bogus.com> Date: Fri, 13 Jul 2012 19:15:40 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120704 Thunderbird/14.0 MIME-Version: 1.0 To: "George, Wes" References: <97A9B2B8-B1D5-4BAE-88C6-A99911EFEB4B@cisco.com> <20120713091447.8C16.8FE1F57E@jpix.ad.jp> <1F4ED938D73A4242BBBB1E7DD492EA0C1672A7E488@PMBX03.gsm1900.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sat, 14 Jul 2012 02:15:47 +0000 (UTC) Cc: "sunset4@ietf.org" Subject: Re: [sunset4] FW: Call for Agenda Items X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 02:15:10 -0000 It is worth noting in case there isn't 100% overlap in the list subscriptions (seems unlikely I know) that there is a rather long history on the v6ops list which can be cruised through the archive. On 7/13/12 5:36 PM, George, Wes wrote: > Folks, the authors of 464xlat have requested that we consider their draft. We're getting feedback that it's not a good fit in v6ops, and may be more appropriate here. Please review and comment. The answers to our questions are below, and are a good example of what we're looking for in terms of justification. > > http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-05 > > Thanks, > > Wes > > > -----Original Message----- > From: Byrne, Cameron [mailto:Cameron.Byrne@T-Mobile.com] > Sent: Friday, July 13, 2012 8:46 AM > To: Fred Baker (fred); MAWATARI Masataka > Cc: Marc Blanchet; George, Wes; joelja@bogus.com jaeggli; Ron Bonica; Ron Bonica; draft-ietf-v6ops-464xlat@tools.ietf.org; Ralph Droms > Subject: RE: [sunset4] Call for Agenda Items > > > 1) describe the problem to be solved and show that there is widespread demand for a solution > > Problem = Fast growing edge networks require IPv4 service but IPv4 addresses are not available. IPv6-only service, including in combination with NAT64/DNS64, is not a sufficient consumer offering since many applications (including Skype) require IPv4 because they use IPv4 literals in their signaling or make IPv4-only socket calls. Thus, these applications require IPv4. Our approximation is that 15% of application in the Android market require IPv4 and do not work without it. > > Further description of why IPv6-only is not sufficient here http://tools.ietf.org/html/rfc6586 > > We believe the list traffic on this topic has shown widespread demand (T-Mobile USA, T-Mobile CZ, Rogers, TW Cable, BT, and representatives from other service providers have noted on-list that this solution has value ... and Android open source implementation is available and a commercial solution from NEC) > > 2) demonstrate that the problem cannot be solved with existing technologies > > There is no available solution today, aside from the implementations of 464XLAT, that allow an Android phone with an IPv6-only connection (with or without NAT64/DNS64) to make a Skype call or stream a Netflix movie. > > MAP solutions are in an adjacent space but are not acceptable for the following reasons. > > First, they require static port mapping. The static port mapping is not as efficient as stateful dynamic NAT, especially given that port overloading can allows 1 IPv4 address to source 100s of thousands of NAT64 connections. For example, how many IPv4 addresses would it take to launch a new LTE service for 20 Million customers? At 1024 ports per customer? ... those address are not feasible to get without great expense with a MAP static mapping. > > Second, it is not possible for an existing service provider, who by RIR policy is required to be at least 80% deployed from their IPv4 reserves ... to launch MAP. Meaning, if I have the vast majority of my addresses deployed, it would not possible to easily move my deployed addresses into a MAP pool. This is especially the case for operators that already have stateful CGN, moving to less address efficient MAP is not feasible with limited addresses. > > Finally, MAP requires DHCPv6. This is not available in 3GPP networks (GSM / UMTS / LTE ) > > "Stateful DHCPv6-based address configuration [RFC3315] is > not supported by 3GPP specifications." > > http://tools.ietf.org/html/rfc6459 > > 3) provide a description of the proposed solution along with its impact on current IPv4-only use and justification that it does not harm or delay the deployment of IPv6 > > > First, IPv6 access networks are a pre-requisite for the 464XLAT architecture, the architecture is explicitly made to enhance and expedite the effectiveness of IPv6-only networks. Also, from a network provider perspective, translation traffic cost more to operate, so the SP will be incented to encourage IPv6 native traffic. > > Description from the abstract: > > This document describes an architecture (464XLAT) for providing > limited IPv4 connectivity across an IPv6-only network by combining > existing and well-known stateful protocol translation RFC 6146 in the > core and stateless protocol translation RFC 6145 at the edge. 464XLAT > is a simple and scalable technique to quickly deploy limited IPv4 > access service to IPv6-only edge networks without encapsulation. > > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use 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 dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. > _______________________________________________ > sunset4 mailing list > sunset4@ietf.org > https://www.ietf.org/mailman/listinfo/sunset4 > From liushucheng@huawei.com Sun Jul 15 21:02:20 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29FDA21F84E7 for ; Sun, 15 Jul 2012 21:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.722 X-Spam-Level: X-Spam-Status: No, score=-5.722 tagged_above=-999 required=5 tests=[AWL=-0.876, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, 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 1SqILMx+iznw for ; Sun, 15 Jul 2012 21:02:19 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3885221F84E6 for ; Sun, 15 Jul 2012 21:02:19 -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 AHU07526; Mon, 16 Jul 2012 00:03:02 -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; Sun, 15 Jul 2012 21:00:20 -0700 Received: from SZXEML414-HUB.china.huawei.com (10.82.67.153) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 15 Jul 2012 21:00:20 -0700 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.75]) by SZXEML414-HUB.china.huawei.com ([10.82.67.153]) with mapi id 14.01.0323.003; Mon, 16 Jul 2012 12:00:17 +0800 From: "Will Liu (Shucheng)" To: Dan Wing Thread-Topic: [sunset4] FW: draft-li-behave-NAT444-Test and draft-tsou-stateless-nat44 Thread-Index: AQHNX4RnwCgS5HEOlEWfGEfnxNdwUZcrOSng Date: Mon, 16 Jul 2012 04:00:16 +0000 Message-ID: References: <0a5501cd5f84$6271cf40$27556dc0$@com> In-Reply-To: <0a5501cd5f84$6271cf40$27556dc0$@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="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "'George, Wes'" , "sunset4@ietf.org" Subject: Re: [sunset4] FW: draft-li-behave-NAT444-Test and draft-tsou-stateless-nat44 X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 04:02:20 -0000 VGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLiBGb2xsb3dpbmdzIGFyZSBteSByZXBseSB0byB0aGVt Lg0KMSlJIHdpbGwgcmVhZCB0aG9zZSBkcmFmdHMgeW91IG1lbnRpb25lZCBhbmQgc2VhcmNoIHlv dXIgY29tbWVudHMuIA0KMilXaGF0IHdlIHByb3Bvc2VkIGlzIGZvY3VzZWQgdG8gZG8gYW5kIG9u bHkgZG8gbW9kaWZpY2F0aW9uIG9uIHRoZSBDR04sIHdpdGhvdXQgdG9vIG1hbnkgY2hhbmdlcyBv biB0aGUgY3VycmVudCB2NCBuZXR3b3JrLiBNYXAgd2l0aCBJUHY2IGlzIGFub3RoZXIgc2NlbmFy aW8uDQozKSBTaG91bGQgYmUgImJ5cGFzcyIuIFNvcnJ5IGZvciB0aGF0Lg0KDQpDaGVlcnMsDQpX aWxsDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBzdW5zZXQ0LWJv dW5jZXNAaWV0Zi5vcmcgW21haWx0bzpzdW5zZXQ0LWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+IEJl aGFsZiBPZiBEYW4gV2luZw0KPiBTZW50OiBUaHVyc2RheSwgSnVseSAxMiwgMjAxMiAxMjo0NCBB TQ0KPiBUbzogJ0dlb3JnZSwgV2VzJzsgc3Vuc2V0NEBpZXRmLm9yZzsgV2lsbCBMaXUgKFNodWNo ZW5nKQ0KPiBTdWJqZWN0OiBSZTogW3N1bnNldDRdIEZXOiBkcmFmdC1saS1iZWhhdmUtTkFUNDQ0 LVRlc3QgYW5kDQo+IGRyYWZ0LXRzb3Utc3RhdGVsZXNzLW5hdDQ0DQo+IA0KPiA+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogc3Vuc2V0NC1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86c3Vuc2V0NC1ib3VuY2VzQGlldGYub3JnXSBPbg0KPiA+IEJlaGFsZiBPZiBHZW9yZ2Us IFdlcw0KPiA+IFNlbnQ6IFdlZG5lc2RheSwgSnVseSAxMSwgMjAxMiA3OjI0IEFNDQo+ID4gVG86 IHN1bnNldDRAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBbc3Vuc2V0NF0gRlc6IGRyYWZ0LWxpLWJl aGF2ZS1OQVQ0NDQtVGVzdCBhbmQgZHJhZnQtdHNvdS0NCj4gPiBzdGF0ZWxlc3MtbmF0NDQNCj4g Pg0KPiA+IFRoZSBhbnN3ZXJzIHRvIG91ciBxdWVzdGlvbnMgb24gdHdvIGRyYWZ0cyBhcmUgYmVs b3cuIFBsZWFzZSByZXZpZXcgYW5kDQo+ID4gY29tbWVudCBvbiB0aGUgY29udGVudCBvZiB0aGUg YW5zd2VycywgZWl0aGVyIHRvZ2V0aGVyIG9yIHNlcGFyYXRlbHkuDQo+ID4gSSdkIGxpa2Ugc29t ZSBkaXNjdXNzaW9uIG9uIHRoZSBkcmFmdCBvciB0aGUgcXVlc3Rpb25zIG9uLWxpc3QgYmVmb3Jl DQo+ID4gd2UgZ2V0IGludG8gdGhlIG1lZXRpbmcuDQo+IA0KPiBTZWUgYmVsb3cuDQo+IA0KPiA+ IFRoYW5rcw0KPiA+DQo+ID4gV2VzIEdlb3JnZQ0KPiA+DQo+ID4NCj4gPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IFdpbGwgTGl1IChTaHVjaGVuZykgW21haWx0bzpsaXVz aHVjaGVuZ0BodWF3ZWkuY29tXQ0KPiA+IFNlbnQ6IFdlZG5lc2RheSwgSnVseSAxMSwgMjAxMiA1 OjQyIEFNDQo+ID4gVG86IEdlb3JnZSwgV2VzDQo+ID4gQ2M6IHN1bnNldDQtY2hhaXJzQHRvb2xz LmlldGYub3JnDQo+ID4gU3ViamVjdDogQXNraW5nIGZvciB0d28gMTBtaW4gc2xvdHMNCj4gPg0K PiA+IEhpIEdlb3JnZSwNCj4gPg0KPiA+IFRoYW5rcyBmb3IgeW91ciBraW5kbHkgcmVtaW5kaW5n LiBTb3JyeSBmb3IgbXkgY2FyZWxlc3NuZXNzLiA6RCBNYXkgSQ0KPiA+IGFzayBmb3IgMiB0aW1l IHNsb3RzIGZvciBkcmFmdC1MaS1CZWhhdmUtTkFUNDQ0LVRlc3QtMDAgYW5kIGRyYWZ0LXRzb3Ut DQo+ID4gc3RhdGVsZXNzLW5hdDQ0o79FYWNoIHByZXNlbnRhdGlvbiB3b3VsZCBsYXN0IGZvciAx MG1pbiBhbmQgdGhlDQo+ID4gcHJlc2VudGVyIHdpbGwgYmUgV2lsbCBMaXUuDQo+ID4NCj4gPiBG b2xsb3dpbmcgYXJlIG15IGFuc3dlcnMgdG8geW91ciB0aHJlZSBxdWVzdGlvbiBmb3IgYm90aCBk cmFmdHM6DQo+ID4gUToNCj4gPiAxKSBkZXNjcmliZSB0aGUgcHJvYmxlbSB0byBiZSBzb2x2ZWQg YW5kIHNob3cgdGhhdCB0aGVyZSBpcyB3aWRlc3ByZWFkDQo+ID4gZGVtYW5kIGZvciBhIHNvbHV0 aW9uDQo+ID4gMikgZGVtb25zdHJhdGUgdGhhdCB0aGUgcHJvYmxlbSBjYW4gbm90IGJlIHNvbHZl ZCB3aXRoIGV4aXN0aW5nDQo+ID4gdGVjaG5vbG9naWVzDQo+ID4gMykgcHJvdmlkZSBhIGRlc2Ny aXB0aW9uIG9mIHRoZSBwcm9wb3NlZCBzb2x1dGlvbiBhbG9uZyB3aXRoIGl0cyBpbXBhY3QNCj4g PiBvbiBjdXJyZW50IElQdjQtb25seSB1c2UgYW5kIGp1c3RpZmljYXRpb24gdGhhdCBpdCBkb2Vz IG5vdCBoYXJtIG9yDQo+ID4gZGVsYXkgdGhlIGRlcGxveW1lbnQgb2YgSVB2Ng0KPiA+DQo+ID4g QToNCj4gPiBkcmFmdC1MaS1CZWhhdmUtTkFUNDQ0LVRlc3QtMDANCj4gPiAxKSBOQVQ0NDQgaXMg YSBjb21tb24gc2NlbmFyaW8gaW4gb3BlcmF0b3Jzoa8gbmV0d29yay4gIE9wZXJhdG9ycyBhcmUN Cj4gPiB3b3JyaWVkIHdoZXRoZXIgYXBwbGljYXRpb25zIHdpbGwgYmUgYWZmZWN0ZWQgd2hlbiB0 aGV5IHBhc3MgdGhvdWdoDQo+ID4gbXVsdGktbGV2ZWwgTkFULiBUaGlzIHRlc3QgZG9jdW1lbnQg cHJvdmlkZXMgZXhwZXJpZW5jZXMgZm9yIGJvdGgNCj4gPiBvcGVyYXRvcnMgYW5kIHJlc2VhcmNo ZXJzLg0KPiA+IDIpIER1cmluZyB0ZXN0aW5nLCB3ZSBmaW5kIHNvbWUgcHJvYmxlbXMgc3VjaCBh cyBRUSBvbmxpbmUgR2FtaW5nDQo+ID4gZG9lc26hr3QgcGVybWl0IHR3byB1c2VyIHdpdGggdGhl IHNhbWUgcHVibGljIElQIGFkZHJlc3MgaW4gc2FtZSBnYW1lDQo+ID4gcm9vbS4NCj4gDQo+IE90 aGVyIGFwcGxpY2F0aW9ucyBoYXZlIGEgc2ltaWxhciByZXN0cmljdGlvbi4gIEZvciBleGFtcGxl LCBNb2hhbWVkDQo+IGhhcyBkb25lIGV4dGVuc2l2ZSB0ZXN0aW5nIHdpdGggQml0VG9ycmVudCBh bmQgZGVzY3JpYmVkIHRoZSBwcmVjaXNlDQo+IHNsb3dkb3ducyBhbmQgdGhlIHByZWNpc2UgZmFp bHVyZXMgd2hlbiB0d28gdXNlcnMgYXJlIHNoYXJpbmcgdGhlDQo+IHNhbWUgSVB2NCBhZGRyZXNz LCBkcmFmdC1ib3VjYWRhaXItcGNwLWJpdHRvcnJlbnQuDQo+IA0KPiBDYWJsZWxhYnMgcHVibGlz aGVkIHJlc3VsdHMgb2Ygc29tZSBvZiB0aGVpciB0ZXN0aW5nIHVzaW5nIGENCj4gZGlmZmVyZW50 IG1peCBvZiBhcHBsaWNhdGlvbnMuICBJIGhhdmUgcHJldmlvdXNseSByYWlzZWQNCj4gb2JqZWN0 aW9ucyB0byB0aGVpciB0ZXN0aW5nIG1ldGhvZG9sb2d5IGFuZCByZXN1bHRzLiAgVGhlaXINCj4g ZG9jdW1lbnQgaXMgZHJhZnQtZG9ubGV5LW5hdDQ0NC1pbXBhY3RzLg0KDQo+IA0KPiA+IDMpIFRo aXMgaXMgYSB0ZXN0aW5nIGRyYWZ0LiBQcm9wb3NlZCBzb2x1dGlvbiBpcyBub3QgcmVsYXRlZC4N Cj4gPg0KPiA+IGRyYWZ0LXRzb3Utc3RhdGVsZXNzLW5hdDQ0LTAwDQo+ID4gMSkgIFRvIGxldCB0 aGUgTkFUNDQgQ0dOIHNpbXBsZSwgdG8gcmVkdWNlIHRoZSBjb3N0IG9mIENHTi4gRGlmZmVyZW50 DQo+ID4gZnJvbSB0cmFkaXRpb25hbCBOQVQ0NDogbm8gcGVyLXNlc3Npb24gc3RhdGUgb24gdGhl IENHTiwgbm8gYmluZGluZw0KPiA+IHRhYmxlLCBubyBwZXItZmxvdyBzdGF0ZSB0byBiZSBtYWlu dGFpbmVkLCB6ZXJvIGxvZywgaGlnaCBzcGVlZCwgZWFzeQ0KPiA+IHRvIGRlcGxveSBob3QgYmFj a3VwLg0KPiA+IDIpICBUcmFkaXRpb25hbCBOQVQ0NCBDR04gbmVlZCBwZXItc2Vzc2lvbiBzdGF0 ZSBvbiB0aGUgQ0dOLCBiaW5kaW5nDQo+ID4gdGFibGUsIHBlci1mbG93IHN0YXRlIHRvIGJlIG1h aW50YWluZWQuIFRoZXNlIG1ha2UgdGhlIENHTiBleHBlbnNpdmUNCj4gPiBhbmQgZGlmZmljdWx0 IHRvIGFjaGlldmUgQ0dOIGhvdCBiYWNrdXAuDQo+ID4gMykgIFNvbHZlIHRoZSBleGhhdXN0aW9u IG9mIElQdjQgYWRkcmVzcyB3aGVuIHRoZSBuZXR3b3JrIG1pZ3JhdGUgdG8NCj4gPiBJUHY2LiBC ZWNhdXNlIGl0IGlzIHN0YXRlbGVzcywgdGhlIElTUHMgZG9uoa90IG5lZWQgdG9vIG11Y2ggY29z dCB0bw0KPiA+IGRlcGxveSBpdC4NCj4gDQo+IFRoaXMgc2VlbXMgdG8gYmUgYSBNQVAgc29sdXRp b24uICBCdXQgZGlmZmVycyBmcm9tIE1BUCBpbiB0aGF0IGl0IHVzZXMNCj4gYW4gSVB2NCBuZXR3 b3JrIGJldHdlZW4gdGhlIHN1YnNjcmliZXIgYW5kIHRoZSBJU1AncyAic3RhdGVsZXNzIE5BVDQ0 Ig0KPiBkZXZpY2UsIHdoZXJlYXMgTUFQIHVzZXMgYW4gSVB2NiBuZXR3b3JrIGJldHdlZW4gdGhl IHN1YnNjcmliZXIgYW5kDQo+IHRoZSBJU1AncyAiTUFQIGJvcmRlciByZWxheSIgZGV2aWNlLg0K PiANCj4gPiBJdCBjYW4gYWxzbyBiZSBpbXBsZW1lbnRlZCBpbiBkdWFsLXN0YWNrIG5ldHdvcmso SVB2NA0KPiA+IHRyYWZmaWMgcGFzcyB0aHJvdWdoIHN0YXRlbGVzcyBOQVQ0NCBhbmQgSVB2NiB0 cmFmZmljIHBhc3MgYnkgc3RhdGVsZXNzDQo+ID4gTkFUNDQpLCBzbyB0aGUgbmV0d29yayBjYW4g bWlncmF0ZSB0byBJUHY2IHNtb290aGx5Lg0KPiANCj4gVHlwbyBpbiB0aGF0IHNlbnRlbmNlPw0K PiANCj4gLWQNCj4gDQo+IA0KPiA+IFJlZ2FyZHMsDQo+ID4gV2lsbA0KPiA+DQo+ID4NCj4gPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IEdlb3JnZSwgV2VzIFttYWlsdG86 d2VzbGV5Lmdlb3JnZUB0d2NhYmxlLmNvbV0NCj4gPiBTZW50OiBXZWRuZXNkYXksIEp1bHkgMTEs IDIwMTIgMTI6NDggUE0NCj4gPiBUbzogV2lsbCBMaXUgKFNodWNoZW5nKTsgc3Vuc2V0NC1jaGFp cnNAdG9vbHMuaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBSRTogQXNraW5nIGZvciBhIDEwbWluIHNs b3QNCj4gPg0KPiA+IFBsZWFzZSBzZWUgdGhlIG1lc3NhZ2UgSSBzZW50IHRvIHRoZSBsaXN0IHRo aXMgQU0uDQo+ID4NCj4gPiBUaGFua3MsDQo+ID4NCj4gPiBXZXMNCj4gPg0KPiA+ID4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206IFdpbGwgTGl1IChTaHVjaGVuZykgW21h aWx0bzpsaXVzaHVjaGVuZ0BodWF3ZWkuY29tXQ0KPiA+ID4gU2VudDogVHVlc2RheSwgSnVseSAx MCwgMjAxMiA1OjMwIEFNDQo+ID4gPiBUbzogc3Vuc2V0NC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcN Cj4gPiA+IFN1YmplY3Q6IEFza2luZyBmb3IgYSAxMG1pbiBzbG90DQo+ID4gPg0KPiA+ID4gSGkg Q2hhaXJzLA0KPiA+ID4NCj4gPiA+IEkgYW0gd3JpdGluZyB0byBhc2sgZm9yIGEgMTAgbWluIHNs b3QgZm9yIGEgcHJlc2VudGF0aW9uIGZvcg0KPiA+ID4gZHJhZnQtdHNvdS0gc3RhdGVsZXNzLW5h dDQ0Lg0KPiA+ID4gUHJlc2VudGVyIG5hbWUgaXMgV2lsbCBMaXUgYW5kIGxlbmd0aCBvZiBwcmVz ZW50YXRpb24gaXMgMTAgbWludXRlcy4NCj4gPiA+IFRoYW5rcy4NCj4gPiA+DQo+ID4gPiBIYXZl IGEgbmljZSBkYXkhDQo+ID4gPiBXaWxsDQo+ID4NCj4gPiBUaGlzIEUtbWFpbCBhbmQgYW55IG9m IGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lciBDYWJsZQ0KPiA+IHByb3By aWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9y IHN1YmplY3QNCj4gPiB0byBjb3B5cmlnaHQgYmVsb25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxl LiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRlZA0KPiA+IHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUg aW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMNCj4gPiBhZGRyZXNzZWQuIElmIHlv dSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdQ0KPiA+ IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9u LCBjb3B5aW5nLCBvcg0KPiA+IGFjdGlvbiB0YWtlbiBpbiByZWxhdGlvbiB0byB0aGUgY29udGVu dHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvIHRoaXMgRS0NCj4gPiBtYWlsIGlzIHN0cmljdGx5IHBy b2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQNCj4gPiB0 aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5 IGFuZA0KPiA+IHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFueSBjb3B5IG9m IHRoaXMgRS1tYWlsIGFuZCBhbnkNCj4gPiBwcmludG91dC4NCj4gPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IHN1bnNldDQgbWFpbGluZyBsaXN0 DQo+ID4gc3Vuc2V0NEBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc3Vuc2V0NA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gc3Vuc2V0NCBtYWlsaW5nIGxpc3QNCj4gc3Vuc2V0NEBpZXRmLm9y Zw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N1bnNldDQNCg== From liushucheng@huawei.com Mon Jul 16 02:35:55 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0936321F8627 for ; Mon, 16 Jul 2012 02:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.489 X-Spam-Level: X-Spam-Status: No, score=-6.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 FqWVBIWDviTe for ; Mon, 16 Jul 2012 02:35:51 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 36D1B21F857D for ; Mon, 16 Jul 2012 02:35:51 -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 AIB22258; Mon, 16 Jul 2012 05:36:35 -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; Mon, 16 Jul 2012 02:33:54 -0700 Received: from SZXEML421-HUB.china.huawei.com (10.82.67.160) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 16 Jul 2012 02:33:55 -0700 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.75]) by szxeml421-hub.china.huawei.com ([10.82.67.160]) with mapi id 14.01.0323.003; Mon, 16 Jul 2012 17:33:47 +0800 From: "Will Liu (Shucheng)" To: "George, Wes" Thread-Topic: draft-tsou-stateless-nat44 Thread-Index: Ac1hEHgD9fg1lWZuQdqYd+8o14pBMQB9xa8g Date: Mon, 16 Jul 2012 09:33:46 +0000 Message-ID: References: In-Reply-To: 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: "sunset4@ietf.org" , Dan Wing Subject: Re: [sunset4] draft-tsou-stateless-nat44 X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 09:35:55 -0000 Thanks for your comments. Please see below. Regards, Will > -----Original Message----- > From: George, Wes [mailto:wesley.george@twcable.com] > Sent: Saturday, July 14, 2012 8:36 AM > To: Dan Wing; sunset4@ietf.org; Will Liu (Shucheng) > Subject: RE: draft-tsou-stateless-nat44 >=20 > > From: Dan Wing [mailto:dwing@cisco.com] > > Sent: Wednesday, July 11, 2012 12:44 PM > > To: George, Wes; sunset4@ietf.org; 'Will Liu (Shucheng)' > > Subject: RE: [sunset4] FW: draft-li-behave-NAT444-Test and draft-tsou- > > stateless-nat44 > > > > This seems to be a MAP solution. But differs from MAP in that it uses > > an IPv4 network between the subscriber and the ISP's "stateless NAT44" > > device, whereas MAP uses an IPv6 network between the subscriber and the > > ISP's "MAP border relay" device. >=20 > [WEG] The chief criticism leveled at IPv4-only NAT solutions is that they= do > nothing to encourage IPv6 deployment, and instead function as IPv4 > life-support by allowing carriers to delay deployment of IPv6. The author= s will > have a significant burden of justification as to why this is better than = MAP in > that it doesn't push the implementer to deploy IPv6 on the network (or at > least allow the use of IPv6 as transport). Also, there are already multip= le > competing stateless solutions. I'd rather not add another without a very = good > statement of what problem it's solving that the existing ones do not. Tha= t's > actually the reason for question #2 - "existing technologies" also refers= to > alternate solutions to the same problem that are still in draft, not just= existing > running code. [Will] Our solution excels other stateless ones in the following fields. 1 Security. Our solution employs discontinuous addresses. Therefore attack = with a fake ip address is not an easy work.=20 2 Increase the utilization rate of the port range. Users can be assigned by= a proper-size port range by using the variable prefix pool. >=20 > > > > > It can also be implemented in dual-stack network(IPv4 traffic pass > > > through stateless NAT44 and IPv6 traffic pass by stateless NAT44), so > > > the network can migrate to IPv6 smoothly. > > > > Typo in that sentence? > [WEG] excepting the typo (bypass vs pass by), the draft should say this, = and in > fact should probably say it in stronger terms - "a network using this NAT > SHOULD deploy IPv6, so that all supporting devices and content can bypass > the NAT and maintain end-to-end connectivity" or some similar. This is a = drum > we need to beat in every draft focused on an IPv4-only solution based on = the > way that our charter is written and IETF's overall opinion about IPV4 > life-extension technologies. [Will] Absolutely agree. We will put it into our draft. >=20 > > > > -d >=20 > Thanks, > Wes George, speaking as sunset4 co-chair. >=20 > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject to > copyright belonging to Time Warner Cable. This E-mail is intended solely = for > the use 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 > dissemination, distribution, copying, or action taken in relation to the = contents > of and attachments to this E-mail is strictly prohibited and may be unlaw= ful. If > you have received this E-mail in error, please notify the sender immediat= ely > and permanently delete the original and any copy of this E-mail and any > printout. From simon.perreault@viagenie.ca Mon Jul 16 11:58:01 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0757321F883C for ; Mon, 16 Jul 2012 11:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=0.147, 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 Cybx2vo+lQ4b for ; Mon, 16 Jul 2012 11:58:00 -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 1DB4E21F8847 for ; Mon, 16 Jul 2012 11:58:00 -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 B0080415D1; Mon, 16 Jul 2012 14:58:44 -0400 (EDT) Message-ID: <50046464.1090503@viagenie.ca> Date: Mon, 16 Jul 2012 14:58:44 -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: Dan Wing References: <0a5501cd5f84$6271cf40$27556dc0$@com> In-Reply-To: <0a5501cd5f84$6271cf40$27556dc0$@com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: sunset4@ietf.org, "'George, Wes'" , "'Will Liu \(Shucheng\)'" Subject: [sunset4] Stateless NAT44 vs MAP/4rd X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 18:58:01 -0000 On 07/11/2012 12:44 PM, Dan Wing wrote: >> draft-tsou-stateless-nat44-00 > > This seems to be a MAP solution. But differs from MAP in that it uses > an IPv4 network between the subscriber and the ISP's "stateless NAT44" > device, whereas MAP uses an IPv6 network between the subscriber and > the ISP's "MAP border relay" device. I think this is a fair comparison. One advantage of SLNAT44 over MAP is that the necessary changes to the CPE are minimal. For example, a vanilla Linux can do SLNAT44 today. Another advantage of SLNAT44 is simpler provisioning: CPEs don't need to have access to all the "mapping rules" for direct communication to work. In MAP/4rd, a CPE needs to compute the IPv6 address to which the IPv4 address it wants to reach is mapped. That's why rules need to be downloaded to the CPE. In SLNAT44, you just send the packet directly to the IPv4 address you want to reach. There is no overlay network, so no rules to be downloaded. Simplicity! :) Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Mon Jul 16 12:16:20 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AED1A11E82E4 for ; Mon, 16 Jul 2012 12:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.138, 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 LcIr-4MX5f2y for ; Mon, 16 Jul 2012 12:16:19 -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 B7E9C11E82F8 for ; Mon, 16 Jul 2012 12:16:19 -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 D66D3415D1 for ; Mon, 16 Jul 2012 15:17:04 -0400 (EDT) Message-ID: <500468B0.4000205@viagenie.ca> Date: Mon, 16 Jul 2012 15:17:04 -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: sunset4@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sunset4] draft-tsou-stateless-nat44 X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 19:16:21 -0000 On 07/13/2012 08:36 PM, George, Wes wrote: > [WEG] The chief criticism leveled at IPv4-only NAT solutions is that > they do nothing to encourage IPv6 deployment, and instead function as > IPv4 life-support by allowing carriers to delay deployment of IPv6. > The authors will have a significant burden of justification as to why > this is better than MAP in that it doesn't push the implementer to > deploy IPv6 on the network (or at least allow the use of IPv6 as > transport). You know what, I'm an optimist. I believe operators when they say they do want to deploy IPv6, and I believe they're doing it. I see IPv6 doing pretty good. It's getting deployed. I think we can fully decouple the problem of IPv6 deployment and residual IPv4 access. We're beyond that now. I don't think tying IPv6 to a residual IPv4 access protocol will have any impact on IPv6 adoption. It's already getting adopted quite nicely. > Also, there are already multiple competing stateless > solutions. I'd rather not add another without a very good statement > of what problem it's solving that the existing ones do not. That's > actually the reason for question #2 - "existing technologies" also > refers to alternate solutions to the same problem that are still in > draft, not just existing running code. See my response to Dan Wing for two advantages of SLNAT44 over MAP. 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 wesley.george@twcable.com Tue Jul 17 08:49:28 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A7C021F86EC for ; Tue, 17 Jul 2012 08:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.156 X-Spam-Level: X-Spam-Status: No, score=-1.156 tagged_above=-999 required=5 tests=[AWL=0.307, 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 york0YURMQgI for ; Tue, 17 Jul 2012 08:49:28 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id DBB2521F86F1 for ; Tue, 17 Jul 2012 08:49:27 -0700 (PDT) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.77,603,1336363200"; d="scan'208";a="410990644" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 17 Jul 2012 11:49:10 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Tue, 17 Jul 2012 11:49:26 -0400 From: "George, Wes" To: Simon Perreault , "sunset4@ietf.org" Date: Tue, 17 Jul 2012 11:49:22 -0400 Thread-Topic: [sunset4] draft-tsou-stateless-nat44 Thread-Index: Ac1jh63S83d/wgw1SJOXDJPtTrkkDAAqAW4w Message-ID: References: <500468B0.4000205@viagenie.ca> In-Reply-To: <500468B0.4000205@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sunset4] draft-tsou-stateless-nat44 X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 15:49:28 -0000 > -----Original Message----- > From: sunset4-bounces@ietf.org [mailto:sunset4-bounces@ietf.org] On > Behalf Of Simon Perreault > Sent: Monday, July 16, 2012 3:17 PM > To: sunset4@ietf.org > Subject: Re: [sunset4] draft-tsou-stateless-nat44 > > On 07/13/2012 08:36 PM, George, Wes wrote: > > [WEG] The chief criticism leveled at IPv4-only NAT solutions is that > > they do nothing to encourage IPv6 deployment, and instead function as > > IPv4 life-support by allowing carriers to delay deployment of IPv6. > > The authors will have a significant burden of justification as to why > > this is better than MAP in that it doesn't push the implementer to > > deploy IPv6 on the network (or at least allow the use of IPv6 as > > transport). > > You know what, I'm an optimist. I believe operators when they say they > do want to deploy IPv6, and I believe they're doing it. I see IPv6 doing > pretty good. It's getting deployed. I think we can fully decouple the > problem of IPv6 deployment and residual IPv4 access. We're beyond that > now. I don't think tying IPv6 to a residual IPv4 access protocol will > have any impact on IPv6 adoption. It's already getting adopted quite > nicely. > [WEG] I appreciate (and to some extent share) your optimism. However, there= are a lot of pessimists (and a fair amount of religious fervor) hanging ou= t in this corner of the IETF. I can point you to several thousand messages = about what became RFC6598 by way of an illustration, that people still beli= eve that IPv4 life extension is a crutch for those who are behind on IPv6 d= eployment, or worse, not deploying. :-) Drafts that don't have words reinfo= rcing IPv4 extension as a temporary thing tend to perpetuate that notion, a= nd attract those folks into delaying/opposing what may otherwise be a solid= idea, simply because it prolongs the agony. IESG's guidance has been pretty clear that it isn't acceptable to assume th= at IPv6 is moving along and focus on residual IPv4 as a completely separate= problem. The impression I have is that they will be resistant to solutions= that don't at least superficially help move the deploying network towards = better IPv6 support while they solve the short-term problem with IPv4 exhau= stion and legacy support. I'm not saying "we shouldn't do this" or "we shouldn't discuss this" becaus= e it uses IPv4 transport. I'm simply noting that you have a burden of proof= based on our charter and the sentiment behind it (since it was written by = IESG) that you would do well to consider while writing the draft, so that y= ou're covered well before it hits IETF last call. Thanks Wes George, speaking as co-chair 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 wesley.george@twcable.com Tue Jul 17 09:45:34 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E21D021F86A7 for ; Tue, 17 Jul 2012 09:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.673 X-Spam-Level: X-Spam-Status: No, score=-0.673 tagged_above=-999 required=5 tests=[AWL=-0.210, 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 g20RgGJbJ3hZ for ; Tue, 17 Jul 2012 09:45:33 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD9221F86B6 for ; Tue, 17 Jul 2012 09:45:33 -0700 (PDT) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.77,604,1336363200"; d="scan'208";a="393634266" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 17 Jul 2012 12:45:33 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Tue, 17 Jul 2012 12:45:56 -0400 From: "George, Wes" To: "Will Liu (Shucheng)" Date: Tue, 17 Jul 2012 12:45:45 -0400 Thread-Topic: draft-tsou-stateless-nat44 Thread-Index: Ac1hEHgD9fg1lWZuQdqYd+8o14pBMQB9xa8gAEmBsuA= Message-ID: References: In-Reply-To: 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 Cc: "sunset4@ietf.org" , Dan Wing Subject: Re: [sunset4] draft-tsou-stateless-nat44 X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 16:45:35 -0000 Also, there are already > multiple > > competing stateless solutions. I'd rather not add another without a > very good > > statement of what problem it's solving that the existing ones do not. > That's > > actually the reason for question #2 - "existing technologies" also > refers to > > alternate solutions to the same problem that are still in draft, not > just existing > > running code. > > [Will] Our solution excels other stateless ones in the following fields. > 1 Security. Our solution employs discontinuous addresses. Therefore > attack with a fake ip address is not an easy work. > 2 Increase the utilization rate of the port range. Users can be assigned > by a proper-size port range by using the variable prefix pool. > > > > > [WEG] Is there a reason that these improvements couldn't be incorporated in= to the other stateless solutions to optimize them (vs being their own separ= ate implementation)? I ask partially out of ignorance - I honestly don't know based on the curre= nt draft and subsequent explanations if there is a technical reason why we = need a separate implementation instead of optimizing the existing one(s). B= ut I also ask to further illustrate my point about existing technologies an= d justification: IETF has far too many drafts out there that could be summa= rized as: "this is like solution X, but it does this one thing differently,= so it's better" or "solution X solves every use case but this one, so we'v= e come up with a different solution that solves for this one corner case" a= nd "no, it's just different enough that we couldn't possibly consider integ= rating the ideas." Then the two (or 3, or 4, or 5! ) solutions compete for = the same resources within the WG, and we end up with impasses like we have = in Softwire [1, 2] or RRG [3], where neither group of authors is willing to= compromise and the group can't seem to get to consensus to pick a "winner"= . The result is that we either have multiple competing solutions, or progre= ss stalls, or likely both. Given that this solution exists in the same spac= e as the example I cited, I'm justifiably concerned. Speaking personally, I like the concept of this working without specific CP= E support, but as a chair, I'm not satisfied with this justification so far= . References: [1] http://www.ietf.org/mail-archive/web/softwires/current/msg03734.html [2] http://www.ietf.org/mail-archive/web/softwires/current/msg04221.html [3] RFC6115 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 wesley.george@twcable.com Tue Jul 17 11:48:29 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E49F21F85D0 for ; Tue, 17 Jul 2012 11:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.662 X-Spam-Level: X-Spam-Status: No, score=-0.662 tagged_above=-999 required=5 tests=[AWL=-0.199, 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 ocnzqwV3hgOY for ; Tue, 17 Jul 2012 11:48:28 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 20EB721F8565 for ; Tue, 17 Jul 2012 11:48:28 -0700 (PDT) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.77,604,1336363200"; d="scan'208";a="393738956" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 17 Jul 2012 14:48:49 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Tue, 17 Jul 2012 14:49:15 -0400 From: "George, Wes" To: "Donley, Chris (Cable Labs)" , "sunset4@ietf.org" Date: Tue, 17 Jul 2012 14:49:14 -0400 Thread-Topic: [sunset4] FW: New Version Notification for draft-donley-behave-deterministic-cgn-04.txt Thread-Index: Ac1fqvG6fLixMu2NTJW4HQJVNxusHAEoCuGQ Message-ID: References: <20120711210254.20594.88768.idtracker@ietfa.amsl.com> In-Reply-To: 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 Subject: Re: [sunset4] FW: New Version Notification for draft-donley-behave-deterministic-cgn-04.txt X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 18:48:29 -0000 If you are not familiar with this document from its prior discussion in oth= er WGs, please be aware that there is an IPR disclosure for it: https://dat= atracker.ietf.org/ipr/1617/ I note that there are currently no licensing terms, and thus direct the aut= hors to section 6.5 of RFC3979: Since IPR disclosures will be used by IETF working groups during their evaluation of alternative technical solutions, it is helpful if an IPR disclosure includes information about licensing of the IPR in case Implementing Technologies require a license. Specifically, it is helpful to indicate whether, upon approval by the IESG for publication as RFCs of the relevant IETF specification(s), all persons will be able to obtain the right to implement, use, distribute and exercise other rights with respect to an Implementing Technology a) under a royalty-free and otherwise reasonable and non- discriminatory license, or b) under a license that contains reasonable and non-discriminatory terms and conditions, including a reasonable royalty or other payment, or c) without the need to obtain a license from the IPR holder. The inclusion of licensing information in IPR disclosures is not mandatory but it is encouraged so that the working groups will have as much information as they can during their deliberations. Thanks, Wes George, Sunset4 co-chair > -----Original Message----- > From: sunset4-bounces@ietf.org [mailto:sunset4-bounces@ietf.org] On > Behalf Of Chris Donley > Sent: Wednesday, July 11, 2012 5:22 PM > To: sunset4@ietf.org > Subject: [sunset4] FW: New Version Notification for draft-donley-behave- > deterministic-cgn-04.txt > > I would like to discuss deterministic-cgn in Vancouver. In answer to > the three questions: > > 1) describe the problem to be solved and show that there is widespread > demand for a solution > > > Abuse response in a Carrier Grade NAT environment requires Service > Providers to be able to map a subscriber=B9s inside address with the > address used on the public Internet. Unfortunately, many Carrier Grade > NAT abuse-response solutions require per-connection logging. Research > indicates that such logging is not scalable to many residential > broadband services. > > CableLabs has been approached by a group of Internet Service Providers > and international public safety organizations to identify a solution to > this problem. In addition, we discussed this approach at the last two > IETF meetings, and heard from ISPs that there is widespread demand for > this solution. > > > 2) demonstrate that the problem can not be solved with existing > Technologies > > > The > existing solutions =AD per-connection logging and bulk-port logging still > pose an impact on ISPs and public safety officials for logging and > searching. Our approach deterministically maps internal addresses to > {external address + port range} in such a way as to be able to > algorithmically calculate the mapping. > Only inputs and configuration of the algorithm need to be logged. This > approach reduces both logging volume and subscriber identification times > while increasing subscriber privacy (i.e. by not logging activity). > > > 3) > provide a description of the proposed solution along with its impact on > current IPv4-only use and justification that it does not harm or delay > the deployment of IPv6 > > > The > solution described in this document is applicable to Carrier Grade NAT > transition technologies (e.g. NAT444, DS-Lite, and NAT64). The authors > acknowledge that native IPv6 will offer subscribers a better experience > than CGN. However, many CPE devices only support IPv4. Likewise, only > approximately 4% of the top 1 million websites are available using IPv6. > Accordingly, deterministic CGN should in no way be understood as making > CGN a replacement for IPv6 service. The authors encourage device > manufacturers to consider RFC 6540 and include IPv6 support. In the > interim, however, CGN has already been deployed in some ISP networks. > Deterministic CGN will provide ISPs with the ability to quickly respond > to public safety requests without requiring excessive infrastructure, > operations, and bandwidth to support per-connection logging. > > > > > The latest update addresses each of these in the text. > Chris > -- > Chris Donley > CCIE, CISSP, SCiPM > Director - Network Technologies > CableLabs=AE > 858 Coal Creek Circle > Louisville, CO 80027 > 303-661-3480 (v) > > > > > > > > On 7/11/12 3:02 PM, "internet-drafts@ietf.org" drafts@ietf.org> > wrote: > > > > >A new version of I-D, draft-donley-behave-deterministic-cgn-04.txt > >has been successfully submitted by Chris Donley and posted to the > >IETF repository. > > > >Filename: draft-donley-behave-deterministic-cgn > >Revision: 04 > >Title: Deterministic Address Mapping to Reduce Logging in > Carrier Grade > >NAT Deployments > >Creation date: 2012-07-11 > >WG ID: Individual Submission > >Number of pages: 14 > >URL: > >http://www.ietf.org/internet-drafts/draft-donley-behave-deterministic- > cgn- > >04.txt > >Status: > >http://datatracker.ietf.org/doc/draft-donley-behave-deterministic-cgn > >Htmlized: > >http://tools.ietf.org/html/draft-donley-behave-deterministic-cgn-04 > >Diff: > >http://tools.ietf.org/rfcdiff?url2=3Ddraft-donley-behave-deterministic- > cgn-0 > >4 > > > >Abstract: > > Abuse response in a Carrier Grade NAT environment requires Service > > Providers to be able to map a subscriber's inside address with the > > address used on the public Internet. Unfortunately, many Carrier > > Grade NAT abuse-response solutions require per-connection logging. > > Research indicates that such logging is not scalable to many > > residential broadband services. This document suggests a way to > > manage Carrier Grade NAT translations in such a way as to > > significantly reduce the amount of logging required while providing > > traceability for abuse response. While the authors acknowledge that > > IPv6 is a preferred solution, Carrier Grade NAT is a reality in many > > networks, and is needed in situations where either customer > equipment > > or Internet content only supports IPv4; this approach should in no > > way slow the deployment of IPv6. > > > > > > > > > > > > > >The IETF Secretariat 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 wesley.george@twcable.com Wed Jul 18 08:50:49 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56CC221F8713 for ; Wed, 18 Jul 2012 08:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.152 X-Spam-Level: X-Spam-Status: No, score=-1.152 tagged_above=-999 required=5 tests=[AWL=0.311, 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 wmkU2jBfsOSi for ; Wed, 18 Jul 2012 08:50:48 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id B8F0121F86FA for ; Wed, 18 Jul 2012 08:50:48 -0700 (PDT) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.77,610,1336363200"; d="scan'208";a="411717267" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 18 Jul 2012 11:50:46 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Wed, 18 Jul 2012 11:51:04 -0400 From: "George, Wes" To: "sunset4@ietf.org" Date: Wed, 18 Jul 2012 11:51:03 -0400 Thread-Topic: Gen-ART review of draft-ietf-behave-lsn-requirements-07 Thread-Index: Ac1kbsYlhnDu4ysiQbybhX3Y9eCDRgAjRgEg Message-ID: References: <4FF2E47C.80104@isode.com> <2D34DBB5-543F-47A3-A649-BDDFF76A6438@netapp.com> <5005B58F.40608@qualcomm.com> <5005EC6A.8030805@qualcomm.com> In-Reply-To: <5005EC6A.8030805@qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sunset4] FW: Gen-ART review of draft-ietf-behave-lsn-requirements-07 X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 15:50:49 -0000 This is an excerpt of a discussion about draft-ietf-behave-lsn-requirements= and which type of document it should be, but I think that Pete makes some = good points about CGN that will help us in navigating how to proceed on our= CGN-related work Thanks, Wes George -----Original Message----- From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Pet= e Resnick Sent: Tuesday, July 17, 2012 6:51 PM To: John C Klensin Cc: draft-ietf-behave-lsn-requirements.all@tools.ietf.org; Alexey Melnikov;= gen-art@ietf.org; ietf@ietf.org Subject: Re: Gen-ART review of draft-ietf-behave-lsn-requirements-07 [WEG] snip this document is about CGNs. It's about things that are almost by definitio= n not nice interoperable players on the Internet. They are messy local devi= ces for (albeit large) local networks. Indeed, there are many folks who thi= nk that horrific plagues be visited upon those who deploy CGNs and that the= y should be dismantled as soon as humanly possible, if not before. But in a= ny event, this is not really a spec "for hardware and software required for= computer communication across interconnected networks", but rather is a do= cument for "networks operated by a great variety of organizations, with div= erse goals and rules" to provide "operators and administrators of the Inter= net follow some common guidelines for policies and operations". 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 phdgang@gmail.com Thu Jul 19 23:00:36 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 579C121F8642 for ; Thu, 19 Jul 2012 23:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 8OyHjlcT4cxB for ; Thu, 19 Jul 2012 23:00:35 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6A0C321F8552 for ; Thu, 19 Jul 2012 23:00:35 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so2873410vcb.31 for ; Thu, 19 Jul 2012 23:01:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oz/TNOkcqbLU57XCkJ+kiGr9FtmVFUMZwqnyJ0bRnZ4=; b=LbZWij8jucuK9FCO324thzk4HqQk97oBUfVOS7PaW07bZDMF7ekuLgHwCRQ8r06wWL ShFF8QGkRFmgQ8BDcTLnWKPUHniiOLULFNSD5VEX+YQzUv/pnBCO5B+B61YVPPFNGBkQ ooX1DGGU9T4BAOUJkQIil2TuKGkUxWiRcuS9iaNDaP4XSTHgyyAuzywJjnGvHJ3fi7SH jeEameXkg9pGuWRo9YkXZMnBAuPb2ZJqA4YOvTV15+rEyNRNb+owCDzrSmvz3FBNZLWX qcnGtMnXdDIT1ZSH5UeT4YYTBxv5mfEngM6U2VrMNxxECPRSVE6OVpsRDVnqDlXFPAEh cCOQ== MIME-Version: 1.0 Received: by 10.220.149.79 with SMTP id s15mr3261434vcv.71.1342764090051; Thu, 19 Jul 2012 23:01:30 -0700 (PDT) Received: by 10.58.4.40 with HTTP; Thu, 19 Jul 2012 23:01:30 -0700 (PDT) In-Reply-To: <50046464.1090503@viagenie.ca> References: <0a5501cd5f84$6271cf40$27556dc0$@com> <50046464.1090503@viagenie.ca> Date: Fri, 20 Jul 2012 14:01:30 +0800 Message-ID: From: GangChen To: Simon Perreault Content-Type: text/plain; charset=ISO-8859-1 Cc: "George, Wes" , sunset4@ietf.org, Dan Wing , "Will Liu \(Shucheng\)" Subject: Re: [sunset4] Stateless NAT44 vs MAP/4rd X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 06:00:36 -0000 The draft is quite interesting One question for clarification Is the mapping between Internal Prefix & External Prefix 1:1 or N:1 ? BRs Gang 2012/7/17, Simon Perreault : > On 07/11/2012 12:44 PM, Dan Wing wrote: >>> draft-tsou-stateless-nat44-00 >> >> This seems to be a MAP solution. But differs from MAP in that it uses >> an IPv4 network between the subscriber and the ISP's "stateless NAT44" >> device, whereas MAP uses an IPv6 network between the subscriber and >> the ISP's "MAP border relay" device. > > I think this is a fair comparison. > > One advantage of SLNAT44 over MAP is that the necessary changes to the > CPE are minimal. For example, a vanilla Linux can do SLNAT44 today. > > Another advantage of SLNAT44 is simpler provisioning: CPEs don't need to > have access to all the "mapping rules" for direct communication to work. > In MAP/4rd, a CPE needs to compute the IPv6 address to which the IPv4 > address it wants to reach is mapped. That's why rules need to be > downloaded to the CPE. In SLNAT44, you just send the packet directly to > the IPv4 address you want to reach. There is no overlay network, so no > rules to be downloaded. > > Simplicity! :) > > 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 > From liushucheng@huawei.com Fri Jul 20 00:00:28 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B79B421F85C5 for ; Fri, 20 Jul 2012 00:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.519 X-Spam-Level: X-Spam-Status: No, score=-6.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 8zC7knn6HRJr for ; Fri, 20 Jul 2012 00:00:27 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id A886121F85C4 for ; Fri, 20 Jul 2012 00:00:27 -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 AHX55208; Fri, 20 Jul 2012 03:01: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; Thu, 19 Jul 2012 23:58:04 -0700 Received: from SZXEML431-HUB.china.huawei.com (10.72.61.39) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 19 Jul 2012 23:58:02 -0700 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.75]) by szxeml431-hub.china.huawei.com ([10.72.61.39]) with mapi id 14.01.0323.003; Fri, 20 Jul 2012 14:57:55 +0800 From: "Will Liu (Shucheng)" To: GangChen Thread-Topic: [sunset4] Stateless NAT44 vs MAP/4rd Thread-Index: AQHNY4UKko7wvAWAH0ymREbo3X/by5cxLRAAgACIfDA= Date: Fri, 20 Jul 2012 06:57:54 +0000 Message-ID: References: <0a5501cd5f84$6271cf40$27556dc0$@com> <50046464.1090503@viagenie.ca> In-Reply-To: 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: Simon Perreault , Dan Wing , "sunset4@ietf.org" , "George, Wes" Subject: Re: [sunset4] Stateless NAT44 vs MAP/4rd X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 07:00:28 -0000 Thanks for your interests in our draft.=20 I am not quite sure whether you were asking the mapping between prefixs or = IPs. Let me explain both. In our method, mapping between internal prefix an= d external prefix is 1:1, while mapping between internal IP and external IP= is N:1. As shown in Figure 2 and 3, the length of external prefix is longe= r than the internal prefix. More specifically, the difference between them = is the length of port set id. Did this answer the question, or do you have = other questions regarding the mapping? Regards, Will > -----Original Message----- > From: sunset4-bounces@ietf.org [mailto:sunset4-bounces@ietf.org] On > Behalf Of GangChen > Sent: Friday, July 20, 2012 2:02 PM > To: Simon Perreault > Cc: George, Wes; sunset4@ietf.org; Dan Wing; Will Liu (Shucheng) > Subject: Re: [sunset4] Stateless NAT44 vs MAP/4rd >=20 > The draft is quite interesting > One question for clarification >=20 > Is the mapping between Internal Prefix & External Prefix 1:1 or N:1 ? >=20 > BRs >=20 > Gang >=20 > 2012/7/17, Simon Perreault : > > On 07/11/2012 12:44 PM, Dan Wing wrote: > >>> draft-tsou-stateless-nat44-00 > >> > >> This seems to be a MAP solution. But differs from MAP in that it uses > >> an IPv4 network between the subscriber and the ISP's "stateless NAT44" > >> device, whereas MAP uses an IPv6 network between the subscriber and > >> the ISP's "MAP border relay" device. > > > > I think this is a fair comparison. > > > > One advantage of SLNAT44 over MAP is that the necessary changes to the > > CPE are minimal. For example, a vanilla Linux can do SLNAT44 today. > > > > Another advantage of SLNAT44 is simpler provisioning: CPEs don't need t= o > > have access to all the "mapping rules" for direct communication to work= . > > In MAP/4rd, a CPE needs to compute the IPv6 address to which the IPv4 > > address it wants to reach is mapped. That's why rules need to be > > downloaded to the CPE. In SLNAT44, you just send the packet directly to > > the IPv4 address you want to reach. There is no overlay network, so no > > rules to be downloaded. > > > > Simplicity! :) > > > > 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 > > > _______________________________________________ > sunset4 mailing list > sunset4@ietf.org > https://www.ietf.org/mailman/listinfo/sunset4 From phdgang@gmail.com Fri Jul 20 01:00:43 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 888CC21F8602 for ; Fri, 20 Jul 2012 01:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 qBiIt1iulMAd for ; Fri, 20 Jul 2012 01:00:42 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 867EC21F8601 for ; Fri, 20 Jul 2012 01:00:42 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so2946085vcb.31 for ; Fri, 20 Jul 2012 01:01:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2WNme5knmS7GqZlFq2ZxGGxlTYGhParOwU0ekSasdKQ=; b=wtApq4VyMMFsDyx7T5LT4gG68u1SgZOMtBqvlEHF3y6Y6L1wDjlXTmTHA9tEQqtwlw I4X86DY8vLv/0Z/5cXbCYvrDtS/RLqkBOwf58mVQnMMPvFnfPO6WcIxNdajcjBj9ONkv rOY09dTouHqA5BgiUgVvGEjkM6LFS0pcWzrwDRAlTahLFF9F6XMPtFBVZX2x/tMMJd5J 853modDGToioLiUrz1SByZQUxsS1g6JDVcB1myJz7j4hCAH4MU6Yx0vCb40/oBXElo8B jAuLRc7Ol+xFtnzRDm15Nll+i6ys8TGCNeeidkIyg3cSC2RrHlVGiu4kGyNURUXbLroO ByAg== MIME-Version: 1.0 Received: by 10.52.156.47 with SMTP id wb15mr3169396vdb.53.1342771297240; Fri, 20 Jul 2012 01:01:37 -0700 (PDT) Received: by 10.58.4.40 with HTTP; Fri, 20 Jul 2012 01:01:37 -0700 (PDT) In-Reply-To: References: <0a5501cd5f84$6271cf40$27556dc0$@com> <50046464.1090503@viagenie.ca> Date: Fri, 20 Jul 2012 16:01:37 +0800 Message-ID: From: GangChen To: "Will Liu (Shucheng)" Content-Type: text/plain; charset=ISO-8859-1 Cc: Simon Perreault , Dan Wing , "sunset4@ietf.org" , "George, Wes" Subject: Re: [sunset4] Stateless NAT44 vs MAP/4rd X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 08:00:43 -0000 2012/7/20, Will Liu (Shucheng) : > Thanks for your interests in our draft. > > I am not quite sure whether you were asking the mapping between prefixs or > IPs. Let me explain both. In our method, mapping between internal prefix and > external prefix is 1:1, while mapping between internal IP and external IP is > N:1. As shown in Figure 2 and 3, the length of external prefix is longer > than the internal prefix. More specifically, the difference between them is > the length of port set id. Did this answer the question, or do you have > other questions regarding the mapping? Thanks. To be more precise, I guess N=2^(b-a) if I understood correctly In another words, when network assigns external prefix, the multiplexing ratio was been pre-determined by length of internal prefix, i.e. deterministic NAT behaviour BRs Gang > Regards, > Will > > >> -----Original Message----- >> From: sunset4-bounces@ietf.org [mailto:sunset4-bounces@ietf.org] On >> Behalf Of GangChen >> Sent: Friday, July 20, 2012 2:02 PM >> To: Simon Perreault >> Cc: George, Wes; sunset4@ietf.org; Dan Wing; Will Liu (Shucheng) >> Subject: Re: [sunset4] Stateless NAT44 vs MAP/4rd >> >> The draft is quite interesting >> One question for clarification >> >> Is the mapping between Internal Prefix & External Prefix 1:1 or N:1 ? >> >> BRs >> >> Gang >> >> 2012/7/17, Simon Perreault : >> > On 07/11/2012 12:44 PM, Dan Wing wrote: >> >>> draft-tsou-stateless-nat44-00 >> >> >> >> This seems to be a MAP solution. But differs from MAP in that it uses >> >> an IPv4 network between the subscriber and the ISP's "stateless NAT44" >> >> device, whereas MAP uses an IPv6 network between the subscriber and >> >> the ISP's "MAP border relay" device. >> > >> > I think this is a fair comparison. >> > >> > One advantage of SLNAT44 over MAP is that the necessary changes to the >> > CPE are minimal. For example, a vanilla Linux can do SLNAT44 today. >> > >> > Another advantage of SLNAT44 is simpler provisioning: CPEs don't need >> > to >> > have access to all the "mapping rules" for direct communication to >> > work. >> > In MAP/4rd, a CPE needs to compute the IPv6 address to which the IPv4 >> > address it wants to reach is mapped. That's why rules need to be >> > downloaded to the CPE. In SLNAT44, you just send the packet directly to >> > the IPv4 address you want to reach. There is no overlay network, so no >> > rules to be downloaded. >> > >> > Simplicity! :) >> > >> > 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 >> > >> _______________________________________________ >> sunset4 mailing list >> sunset4@ietf.org >> https://www.ietf.org/mailman/listinfo/sunset4 > From simon.perreault@viagenie.ca Fri Jul 20 06:26:23 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB8421F861B for ; Fri, 20 Jul 2012 06:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.079, 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 bsPvW3IWOPo0 for ; Fri, 20 Jul 2012 06:26:22 -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 8CC4821F85C4 for ; Fri, 20 Jul 2012 06:26:22 -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 BF1E840032; Fri, 20 Jul 2012 09:27:17 -0400 (EDT) Message-ID: <50095CB5.4090406@viagenie.ca> Date: Fri, 20 Jul 2012 09:27: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: GangChen References: <0a5501cd5f84$6271cf40$27556dc0$@com> <50046464.1090503@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "sunset4@ietf.org" , Dan Wing , "Will Liu \(Shucheng\)" , "George, Wes" Subject: Re: [sunset4] Stateless NAT44 vs MAP/4rd X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 13:26:23 -0000 Le 2012-07-20 04:01, GangChen a écrit : > To be more precise, I guess N=2^(b-a) if I understood correctly > In another words, when network assigns external prefix, the > multiplexing ratio was been pre-determined by length of internal > prefix, i.e. deterministic NAT behaviour Right. The with SLNAT44 the ISP chooses the address sharing ratio statically, just like A+P/MAP/4rd/etc. 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 wesley.george@twcable.com Fri Jul 20 08:14:52 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA8DC21F8637 for ; Fri, 20 Jul 2012 08:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.078 X-Spam-Level: X-Spam-Status: No, score=0.078 tagged_above=-999 required=5 tests=[AWL=-0.949, BAYES_05=-1.11, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ks0fARgEjFQJ for ; Fri, 20 Jul 2012 08:14:51 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id B4A7621F8630 for ; Fri, 20 Jul 2012 08:14:50 -0700 (PDT) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.77,623,1336363200"; d="scan'208,217";a="395391845" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 20 Jul 2012 11:15:10 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Fri, 20 Jul 2012 11:15:46 -0400 From: "George, Wes" To: "sunset4@ietf.org" Date: Fri, 20 Jul 2012 11:15:44 -0400 Thread-Topic: Draft sunset4 Agenda posted Thread-Index: Ac1mioXc/QO6rv04StiGt13rdWhDeA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_DCC302FAA9FE5F4BBA4DCAD4656937791746DD41A0PRVPEXVS03cor_" MIME-Version: 1.0 Cc: "Brian Haberman \(brian@innovationslab.net\)" , "Ralph Droms \(rdroms.ietf@gmail.com\)" Subject: [sunset4] Draft sunset4 Agenda posted X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 15:14:52 -0000 --_000_DCC302FAA9FE5F4BBA4DCAD4656937791746DD41A0PRVPEXVS03cor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, I have posted a draft agenda for Sunset4. http://www.ietf.org/proceedings/84/agenda/agenda-84-sunset4 I was wrong about the length of our meeting in my previous message, and we = actually have 150 minutes, so I've built an agenda that includes all folks = who have asked to present. Those who have received specific feedback on-lis= t about their drafts should be prepared to respond to it during their prese= ntations. In addition to those who have emailed requesting time, you'll see that draf= t-george-ipv6-support is being discussed. Since this draft is referenced in= our charter as part of the reason for the group's existence, the ADs and c= hairs felt that it is certainly appropriate to get WG feedback on the draft= , and it may be appropriate to actually adopt it as a WG item, so I added t= hat to the agenda. One of my co-authors will be presenting, and a new draft= will be published after we gain some feedback. Feel free to bash on the agenda prior to the actual meeting. Authors, your chairs need to know who is presenting, and we need slides fro= m you by Sunday the 29th so that we have time to upload them prior to the m= eeting. If you walk into our meeting with a thumb drive with your slides on= it, you won't be able to start presenting until your slides are visible on= line. In other words, your agenda time will be used for me or my co-chair t= o upload your presentation. Thanks, Wes George, Sunset4 co-chair ________________________________ 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. --_000_DCC302FAA9FE5F4BBA4DCAD4656937791746DD41A0PRVPEXVS03cor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks, I have posted a draft agenda for Sunset4.

http://www.ietf.org/proceedings/84/agenda/agenda-84-sun= set4

 

I was wrong about the length of our meeting in my pr= evious message, and we actually have 150 minutes, so I’ve built an ag= enda that includes all folks who have asked to present. Those who have rece= ived specific feedback on-list about their drafts should be prepared to respond to it during their presentations.

 

In addition to those who have emailed requesting tim= e, you’ll see that draft-george-ipv6-support is being discussed. Sinc= e this draft is referenced in our charter as part of the reason for the gro= up’s existence, the ADs and chairs felt that it is certainly appropriate to get WG feedback on the draft, and it m= ay be appropriate to actually adopt it as a WG item, so I added that to the= agenda. One of my co-authors will be presenting, and a new draft will be p= ublished after we gain some feedback.

 

Feel free to bash on the agenda prior to the actual = meeting.

 

Authors, your chairs need to know who is presenting,= and we need slides from you by Sunday the 29th so that we have = time to upload them prior to the meeting. If you walk into our meeting with= a thumb drive with your slides on it, you won’t be able to start presenting until your slides are visi= ble online. In other words, your agenda time will be used for me or my co-c= hair to upload your presentation.

 

Thanks,

 

Wes George, Sunset4 co-chair

 


This E-mail and any of its a= ttachments may contain Time Warner Cable proprietary information, which is = privileged, confidential, or subject to copyright belonging to Time Warner = Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.
 --_000_DCC302FAA9FE5F4BBA4DCAD4656937791746DD41A0PRVPEXVS03cor_-- From wesley.george@twcable.com Wed Jul 25 06:42:48 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2164C21F85D5 for ; Wed, 25 Jul 2012 06:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.677 X-Spam-Level: X-Spam-Status: No, score=0.677 tagged_above=-999 required=5 tests=[AWL=-1.461, BAYES_50=0.001, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tr4e20IcTkyC for ; Wed, 25 Jul 2012 06:42:46 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 220F221F85A3 for ; Wed, 25 Jul 2012 06:42:45 -0700 (PDT) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.77,653,1336363200"; d="scan'208,217";a="397288923" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 25 Jul 2012 09:41:52 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Wed, 25 Jul 2012 09:42:44 -0400 From: "George, Wes" To: "sunset4@ietf.org" Date: Wed, 25 Jul 2012 09:40:17 -0400 Thread-Topic: Updates to Sunset4 charter Thread-Index: Ac1qawRo0Rf04oHDSNyV5sqLxyNCFQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_DCC302FAA9FE5F4BBA4DCAD4656937791747A0AC68PRVPEXVS03cor_" MIME-Version: 1.0 Subject: [sunset4] Updates to Sunset4 charter X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 13:42:48 -0000 --_000_DCC302FAA9FE5F4BBA4DCAD4656937791747A0AC68PRVPEXVS03cor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All - The ADs, Marc, and I have been working on some relatively minor updates to = the charter to fix some of the confusion and contradiction that existed in = the first version. These are changes we made after a good bit of discussion= with many of the ADs and WG chairs involved about the purpose of the WG an= d the division of work between ours and other WGs that may have overlap. Or= iginally, the plan was to have these changes approved prior to the meeting = so that a new version was posted, but IESG has decided that they would like= the WG to review them and come to consensus in Vancouver, and then it will= go back to IESG for approval. I wanted to give people time to read the cha= rter before the meeting so that we can get substantive comments, either on = list or in the meeting, and start making forward progress on the actual wor= k that this group should be undertaking. Here is a link to the current charter: http://datatracker.ietf.org/wg/sunse= t4/charter/ Here is a link to the proposed charter: http://www.ietf.org/proceedings/84/= slides/slides-84-sunset4-0.txt And a link to the diff: http://www.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1= =3Dhttp://www.ietf.org/charter/charter-ietf-sunset4-01.txt&url2=3Dhttp://ww= w.ietf.org/proceedings/84/slides/slides-84-sunset4-0.txt or http://tinyurl.= com/clr435p 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. --_000_DCC302FAA9FE5F4BBA4DCAD4656937791747A0AC68PRVPEXVS03cor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All –

 

The ADs, Marc, and I have been working on some relat= ively minor updates to the charter to fix some of the confusion and contrad= iction that existed in the first version. These are changes we made after a= good bit of discussion with many of the ADs and WG chairs involved about the purpose of the WG and the divi= sion of work between ours and other WGs that may have overlap. Originally, = the plan was to have these changes approved prior to the meeting so that a = new version was posted, but IESG has decided that they would like the WG to review them and come to consens= us in Vancouver, and then it will go back to IESG for approval. I wanted to= give people time to read the charter before the meeting so that we can get= substantive comments, either on list or in the meeting, and start making forward progress on the actual wo= rk that this group should be undertaking.

 

Here is a link to the current charter: http://datatracker.ietf.org/wg/sunset4/charter/

 

Here is a link to the proposed charter: http://www.ietf.org/proceedings/84/slides/slides-84-sunset4-0.txt<= /o:p>

 

And a link to the diff: http://www.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=3Dhttp://www.ietf.org/c= harter/charter-ietf-sunset4-01.txt&url2=3Dhttp://www.ietf.org/proceedin= gs/84/slides/slides-84-sunset4-0.txt or http://tinyurl.com/clr435p<= /o:p>

 

Thanks,

 

Wes George

 


This E-mail and any of its a= ttachments may contain Time Warner Cable proprietary information, which is = privileged, confidential, or subject to copyright belonging to Time Warner = Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.
 --_000_DCC302FAA9FE5F4BBA4DCAD4656937791747A0AC68PRVPEXVS03cor_-- From wesley.george@twcable.com Wed Jul 25 08:37:18 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87D4421F8620 for ; Wed, 25 Jul 2012 08:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.523 X-Spam-Level: X-Spam-Status: No, score=-0.523 tagged_above=-999 required=5 tests=[AWL=-0.060, 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 b3Ndj3v+4w+Q for ; Wed, 25 Jul 2012 08:37:17 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 57C5721F861F for ; Wed, 25 Jul 2012 08:37:17 -0700 (PDT) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.77,653,1336363200"; d="scan'208";a="397362270" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 25 Jul 2012 11:36:13 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Wed, 25 Jul 2012 11:37:05 -0400 From: "George, Wes" To: "sunset4@ietf.org" Date: Wed, 25 Jul 2012 11:37:04 -0400 Thread-Topic: NomCom 2012-2013: Second Call for Volunteers Thread-Index: Ac1p198pKt7OjamgR1mq2lbcSL1o/QAo0usQ Message-ID: References: <20120724200604.14449.1507.idtracker@ietfa.amsl.com> In-Reply-To: <20120724200604.14449.1507.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [sunset4] FW: NomCom 2012-2013: Second Call for Volunteers X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 15:37:18 -0000 UGxlYXNlIGNvbnNpZGVyIHZvbHVudGVlcmluZy4uLg0KDQpUaGFua3MsDQoNCldlcw0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaWV0Zi1hbm5vdW5jZS1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86aWV0Zi1hbm5vdW5jZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg Tm9tQ29tIENoYWlyDQpTZW50OiBUdWVzZGF5LCBKdWx5IDI0LCAyMDEyIDQ6MDYgUE0NClRvOiBJ RVRGIEFubm91bmNlbWVudCBMaXN0DQpTdWJqZWN0OiBOb21Db20gMjAxMi0yMDEzOiBTZWNvbmQg Q2FsbCBmb3IgVm9sdW50ZWVycw0KDQpUaGUgTm9tQ29tIDIwMTItMjAxMyBDYWxsIGZvciBWb2x1 bnRlZXJzIGhhcyBub3cgcGFzc2VkIGl0cyBoYWxmd2F5IHBvaW50LiBUaGVyZWZvcmUsIGlmIHlv dSBhcmUgY29uc2lkZXJpbmcgdm9sdW50ZWVyaW5nIHRvIHBhcnRpY2lwYXRlIGluIHRoZSAyMDEy LTIwMTMgTm9tQ29tLCBwbGVhc2UgZG8gc28gc29vbi4NCg0KR2VuZXJhbCBpbmZvcm1hdGlvbiBv biB0aGlzIHllYXIncyBOb21Db20gKGluY2x1ZGluZyBhIGxpc3Qgb2YgcG9zaXRpb25zIHRvIGJl IGZpbGxlZCkgY2FuIGJlIGZvdW5kIGF0OiBodHRwczovL3d3dy5pZXRmLm9yZy9ub21jb20vMjAx Mi8NCg0KVGhlIHN1Y2Nlc3Mgb2YgdGhlIE5vbUNvbSBwcm9jZXNzIGRlcGVuZHMgb24gcmFuZG9t bHkgc2VsZWN0aW5nIGEgY29tbWl0dGVlIHRoYXQgaXMgYSByZXByZXNlbnRhdGl2ZSBzYW1wbGUg b2YgdGhlIG91ciBjb21tdW5pdHkuIFdlIGVuZGVhdm9yIHRvIGhhdmUgYSBOb21Db20gcmVmbGVj dGluZyB0aGUgZGl2ZXJzaXR5IG9mIGV4cGVyaWVuY2UgYW5kIHZpZXdwb2ludHMgdGhhdCBpcyBv dXIgY29tbXVuaXR5J3MgZ3JlYXRlc3Qgc3RyZW5ndGguIEhvd2V2ZXIsIHRvIGFjaGlldmUgdGhp cyBnb2FsIHdlIG11c3QgaGF2ZSB0aGUgbGFyZ2VzdCBwb3NzaWJsZSBwb29sIG9mIHZvbHVudGVl cnMgdGhhdCBmcm9tIHRocm91Z2hvdXQgdGhlIElFVEYgY29tbXVuaXR5Lg0KDQpJIGFtIHBsZWFz ZWQgdG8gcmVwb3J0IHRoYXQgd2UgaGF2ZSBoYWQgYSBzdHJvbmcgaW5pdGlhbCByZXNwb25zZSB0 byB0aGUgRmlyc3QgQ2FsbCBmb3IgVm9sdW50ZWVycywgd2l0aCA3NCBxdWFsaWZpZWQgaW5kaXZp ZHVhbHMgYWdyZWVpbmcgdG8gdm9sdW50ZWVyIHRoZWlyIHRpbWUuIEkgZ3JlYXRseSBhcHByZWNp YXRlIHRoZSBnZW5lcm9zaXR5IGFuZCBjb21taXRtZW50IHRvIG91ciBjb21tdW5pdHkgZXhoaWJp dGVkIGJ5IGFsbCBvZiB0aGVzZSBpbmRpdmlkdWFscy4gSG93ZXZlciwgdGhlIHBvb2wgb2Ygdm9s dW50ZWVycyBpcyBub3QgeWV0IGFzIGRpdmVyc2UgYXMgaXQgc2hvdWxkIGJlIHRvIHJlZmxlY3Qg dGhlIGJyZWFkdGggb2Ygb3VyIGNvbW11bml0eSB3aXRoIHJlZ2FyZHMgdG8gbmF0aW9uYWxpdHks IGdlbmRlciBhbmQgb3JnYW5pemF0aW9uYWwgYWZmaWxpYXRpb24uIFRoZXJlZm9yZSwgSSB3b3Vs ZCBlc3BlY2lhbGx5IGVuY291cmFnZSB0byB2b2x1bnRlZXIgdGhvc2UgaW5kaXZpZHVhbHMgd2hv c2UgcGFydGljaXBhdGlvbiB3b3VsZCBpbmNyZWFzZSB0aGUgZGl2ZXJzaXR5IG9mIG91ciB2b2x1 bnRlZXIgcG9vbC4NCg0KSWYgeW91IGhhdmUgdm9sdW50ZWVyZWQgYmVmb3JlIDEyOjAwIG5vb24g VVRDIG9uIEp1bHkgMjQsIDIwMTIgYW5kIHlvdSBoYXZlIG5vdCByZWNlaXZlZCBhIGNvbmZpcm1h dGlvbiBlbWFpbCBmcm9tIG1lLCB0aGVuIGFuIGVycm9yIGhhcyBvY2N1cnJlZCBhbmQgSSB3b3Vs ZCByZXF1ZXN0IHRoYXQgeW91IHJlc2VuZCB5b3VyIGVtYWlsLg0KDQpEZXRhaWxzIG9uIGhvdyB0 byB2b2x1bnRlZXIgY2FuIGJlIGZvdW5kIGF0IHRoZSBlbmQgb2YgdGhpcyBtZXNzYWdlLiBUbyBz dW1tYXJpemUsIHBsZWFzZSB2b2x1bnRlZXIgYnkgc2VuZGluZyBtZSBhbiBlbWFpbCBjb250YWlu aW5nIHlvdXIgbmFtZSwgYWZmaWxpYXRpb24sIGFuZCB0aGUgZW1haWwgYWRkcmVzcyB5b3UgdXNl IHRvIHJlZ2lzdGVyIGZvciBJRVRGIG1lZXRpbmdzLg0KDQpUaGUgNzQgcXVhbGlmaWVkIGluZGl2 aWR1YWxzIHdobyBoYXZlIHNvIGZhciB2b2x1bnRlZXJlZCBhcmUgbGlzdGVkIGJlbG93LiAgIEkg YXBvbG9naXplIGZvciBhbnkgZXJyb3JzIGluIHRoaXMgbGlzdCwgcGxlYXNlIG5vdGlmeSBtZSBv ZiBhbnkgZXJyb3JzIGFzIHNvb24gYXMgcG9zc2libGUuDQoNClNhbSBBbGRyaW4sIEh1YXdlaQ0K SWduYXMgQmFnZG9uYXMsIENpc2NvDQpMb3UgQmVyZ2VyLCBMYWJOIENvbnN1bHRpbmcNClJhbmR5 IEJ1c2gsIElJSg0KRGVubmlzIENhaSwgQ2lzY28NCkRhbmllbGUgQ2VjY2FyZWxsaSwgRXJpY3Nz b24NCkdhbmcgQ2hlbiwgQ2hpbmEgTW9iaWxlDQpBbmRyYXMgQ3Nhc3phciwgRXJpY3Nzb24NCkh1 aSBEZW5nLCBDaGluYSBNb2JpbGUNCktlaXRoIERyYWdlLCBBbGNhdGVsLUx1Y2VudA0KSm9obiBE cmFrZSwgSnVuaXBlcg0KRG9uYWxkIEVhc3RsYWtlLCBIdWF3ZWkNCkNoYXJsZXMgRWNrZWwsIENp c2NvDQpNZWhtZXQgRXJzdWUsIE5va2lhIFNpZW1lbnMgTmV0d29ya3MNCk1pZ3VlbCBHYXJjaWEs IEVyaWNzc29uDQpFcmljIEdyYXksIEVyaWNzc29uDQpXYXNzaW0gSGFkZGFkLCBFcmljc3Nvbg0K U3RlcGhlbiBIYW5uYSwgSnVuaXBlcg0KU2FtIEhhcnRtYW4sIFBhaW5sZXNzIFNlY3VyaXR5DQpK aWEgSGUsIEh1YXdlaQ0KR2lsZXMgSGVyb24sIENpc2NvDQpQYXVsIEhvZmZtYW4sIFZQTiBDb25z b3J0aXVtDQpDaHJpc3RlciBIb2xtYmVyZywgRXJpY3Nzb24NCkZhbmd3ZWkgSHUsIFpURQ0KQW5k cmV3IEh1dHRvbiwgU2llbWVucyBFbnRlcnByaXNlIENvbW11bmljYXRpb25zIEN1bGxlbiBKZW5u aW5ncywgQ2lzY28gWXVhbmxvbmcgSmlhbmcsIEh1YXdlaSBTaGVuZyBKaWFuZywgSHVhd2VpIExp emhvbmcgSmluLCBaVEUgU3RlcGhlbiBLZW50LCBCQk4gQXJpIEtlcmFuZW4sIEVyaWNzc29uIE5p bmcgS29uZywgQ05OSUMgSm91bmkgS29yaG9uZW4sIE5va2lhIFNpZW1lbnMgTmV0d29ya3MgTWly amEgS3VlaGxld2luZCwgVW5pdmVyc2l0eSBvZiBTdHV0dGdhcnQgRWxpb3QgTGVhciwgQ2lzY28g SG9uZ3l1IExpLCBIdWF3ZWkgR3VvbWFuIExpdSwgWlRFIFdlbmh1IEx1LCBFcmljc3NvbiBZdXhp YSBNYSwgWlRFIEFuZHJldyBNYWxpcywgVmVyaXpvbiBUZXJyeSBNYW5kZXJzb24sIElDQU5OIFNj b3R0IE1hbnNmaWVsZCwgRXJpY3Nzb24gTHVjYSBNYXJ0aW5pLCBDaXNjbyBEYXZpZCBNZXllciwg Q2lzY28gTW9uaXF1ZSBNb3Jyb3csIENpc2NvIFRob21hcyBOYWRlYXUsIEp1bmlwZXIgS2FyZW4g TydEb25vZ2h1ZSwgSW50ZXJuZXQgU29jaWV0eSBCb3JqZSBPaGxtYW4sIEVyaWNzc29uIEtleXVy IFBhdGVsLCBDaXNjbyBUZWVtdSBTYXZvbGFpbmVuLCBOb2tpYSBCZW5zb24gU2NobGllc3Nlciwg SnVuaXBlciBKb2huIFNjdWRkZXIsIEp1bmlwZXIgS2FyZW4gU2VvLCBCQk4gQXJ0dXJvIFNlcnZp biwgTEFDTklDIFNodW8gKFNlYW4pIFNoZW4sIENOTklDIERhdmlkIFNpbmksIEVyaWNzc29uIEhh aWJpbiBTb25nLCBIdWF3ZWkgVG9tIFRheWxvciwgUFQgVGF5bG9yIENvbnN1bHRpbmcgUGFzY2Fs IFRodWJlcnQsIENpc2NvIE1hcmsgVG93bnNsZXksIENpc2NvIFRpbmEgVHNvdSwgSHVhd2VpIEJp bGwgVmVyU3RlZWcsIENpc2NvIFRob21hcyBXYWxzaCwgSnVuaXBlciBZaW54aW5nIFdlaSwgWlRF IFN0ZXBoYW4gV2VuZ2VyLCBWaWR5byBNYWdudXMgV2VzdGVybHVuZCwgRXJpY3Nzb24gU3RldmVu IFdoaXRlLCBBbGNhdGVsLUx1Y2VudCBRaW4gKEJpbGwpIFd1LCBIdWF3ZWkgTGVhZiBZZWgsIEh1 YXdlaSBMaXhpYSBaaGFuZywgVUNMQSBaaGFvaHVpIChKZWZmKSBaaGFuZywgSnVuaXBlciBZaSBa aGFvLCBIdWF3ZWkgUWlhbiAoQ2F0aHkpIFpob3UsIEh1YXdlaSBOaW5nIFpvbmcsIEh1YXdlaQ0K DQpUbyBiZSBlbGlnaWJsZSwgdm9sdW50ZWVycyBmb3IgdGhlIG5vbWNvbSBuZWVkIHRvIGhhdmUg YXR0ZW5kZWQgMyBvZiB0aGUgcGFzdCA1IElFVEYgbWVldGluZ3MgYXMgb2YgdGhlIHRpbWUgdGhp cyBhbm5vdW5jZW1lbnQgZ29lcyBvdXQuIFRoYXQgaXMsIDMgbWVldGluZ3MgZnJvbSBJRVRGIDc5 IChCZWlqaW5nKSAtIElFVEYgODMgKFBhcmlzKS4gSWYgeW91IHF1YWxpZnksIGFuZCBpZiB5b3Ug d2lsbCBub3QgYmUgc2Vla2luZyBhcHBvaW50bWVudCB0byBhbnkgb2YgdGhlIG9wZW4gcG9zaXRp b25zIHRoYXQgdGhpcyBub21jb20gd2lsbCBiZSBmaWxsaW5nLCBwbGVhc2UgY29uc2lkZXIgdm9s dW50ZWVyaW5nLg0KDQpUaGUgcHJpbWFyeSBhY3Rpdml0eSBmb3IgdGhpcyBub21jb20gd2lsbCBi ZWdpbiBpbiBBdWd1c3QgMjAxMiBhbmQgc2hvdWxkIGJlIGNvbXBsZXRlZCBpbiBKYW51YXJ5IDIw MTMuIFRoZSBub21jb20gd2lsbCBiZSBjb2xsZWN0aW5nIHJlcXVpcmVtZW50cyBmcm9tIHRoZSBj b21tdW5pdHksIGFzIHdlbGwgYXMgdGFsa2luZyB0byBjYW5kaWRhdGVzIGFuZCBvYnRhaW5pbmcg ZmVlZGJhY2sgZnJvbSBjb21tdW5pdHkgbWVtYmVycyBhYm91dCBjYW5kaWRhdGVzLiBUaGVyZSB3 aWxsIGJlIHJlZ3VsYXJseSBzY2hlZHVsZWQgY29uZmVyZW5jZSBjYWxscyB0byBlbnN1cmUgcHJv Z3Jlc3MuIFRodXMsIGJlaW5nIGEgbm9tY29tIG1lbWJlciBkb2VzIHJlcXVpcmUgc29tZSB0aW1l IGNvbW1pdG1lbnQuDQoNClBsZWFzZSB2b2x1bnRlZXIgYnkgc2VuZGluZyBhbiBlbWFpbCBiZWZv cmUgMTE6NTkgcG0gRURUIChVVEMgLSA0IGhvdXJzKSBBdWd1c3QgNSwgMjAxMiBhcyBmb2xsb3dz Og0KDQpUbzogbWxlcGluc2tpLmlldGZAZ21haWwuY29tDQpTdWJqZWN0OiBOb21jb20gMjAxMi0x MyBWb2x1bnRlZXINCg0KUGxlYXNlIGluY2x1ZGUgdGhlIGZvbGxvd2luZyBpbmZvcm1hdGlvbiBp biB0aGUgYm9keToNCg0KPFlvdXIgRnVsbCBOYW1lPiAgLy8gQXMgeW91IGVudGVyIGluIHRoZSBJ RVRGIFJlZ2lzdHJhdGlvbiBGb3JtLA0KICAgICAgICAgICAgICAgICAgICAvLyBGaXJzdC9HaXZl biBuYW1lIGZvbGxvd2VkIGJ5IExhc3QvRmFtaWx5IE5hbWUgPEN1cnJlbnQgUHJpbWFyeSBBZmZp bGlhdGlvbj4NCiAgICAgICAgICAgICAgICAvLyB0eXBpY2FsbHkgd2hhdCBnb2VzIGluIHRoZSBD b21wYW55IGZpZWxkDQogICAgICAgICAgICAgICAgLy8gIGluIHRoZSBJRVRGIFJlZ2lzdHJhdGlv biBGb3JtIFs8YWxsIGVtYWlsIGFkZHJlc3NlcyB1c2VkIHRvIFJlZ2lzdGVyIGZvciB0aGUgcGFz dCA1IElFVEYgbWVldGluZ3M+XSA8UHJlZmVycmVkIGVtYWlsIGFkZHJlc3M+ICAvLw0KPFRlbGVw aG9uZSBudW1iZXI+ICAgICAgICAgLy8gRm9yIGNvbmZpcm1hdGlvbiBpZiBzZWxlY3RlZA0KDQpQ bGVhc2UgZXhwZWN0IGFuIGVtYWlsIHJlc3BvbnNlIGZyb20gbWUgd2l0aGluIDMgYnVzaW5lc3Mg ZGF5cyBzdGF0aW5nIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUgcXVhbGlmaWVkLiAgSWYgeW91IGRv bid0IHJlY2VpdmUgYSByZXNwb25zZSwgcGxlYXNlIHJlLXNlbmQgeW91ciBlbWFpbCB3aXRoIHRo ZSB0YWcgIlJFU0VORDoiIGFkZGVkIHRvIHRoZSBzdWJqZWN0IGxpbmUuDQoNCklmIHlvdSBhcmUg bm90IHlldCBzdXJlIHlvdSB3b3VsZCBsaWtlIHRvIHZvbHVudGVlciwgcGxlYXNlIGNvbnNpZGVy IHRoYXQgbm9tY29tIG1lbWJlcnMgcGxheSBhIHZlcnkgaW1wb3J0YW50IHJvbGUgaW4gc2hhcGlu ZyB0aGUgbGVhZGVyc2hpcCBvZiB0aGUgSUVURi4gIEVuc3VyaW5nIHRoZSBsZWFkZXJzaGlwIG9m IHRoZSBJRVRGIGlzIGZhaXIgYW5kIGJhbGFuY2VkIGFuZCBjb21wcmlzZWQgb2YgdGhvc2Ugd2hv IGNhbiBsZWFkIHRoZSBJRVRGIGluIHRoZSByaWdodCBkaXJlY3Rpb24gaXMgYW4gaW1wb3J0YW50 IHJlc3BvbnNpYmlsaXR5IHRoYXQgcmVzdHMgb24gdGhlIElFVEYgcGFydGljaXBhbnRzIGF0IGxh cmdlLiBWb2x1bnRlZXJpbmcgZm9yIHRoZSBub21jb20gaXMgYSBnb29kIHdheSBvZiBjb250cmli dXRpbmcgdG93YXJkIHRoYXQgZ29hbC4NCg0KSSB3aWxsIGJlIHB1Ymxpc2hpbmcgYSBtb3JlIGRl dGFpbGVkIHRpbWV0YWJsZSBmb3Igbm9tY29tIGFjdGl2aXRpZXMsIGFzIHdlbGwgYXMgZGV0YWls cyBvZiB0aGUgcmFuZG9tbmVzcyBzZWVkcyB0byBiZSB1c2VkIGZvciB0aGUgUkZDIDM3OTcgc2Vs ZWN0aW9uIHByb2Nlc3MsIHdpdGhpbiB0aGUgbmV4dCBjb3VwbGUgZGF5cy4NCg0KVGhhbmsgeW91 LA0KTWF0dGhldyBMZXBpbnNraQ0Kbm9tY29tLWNoYWlyQGlldGYub3JnIChvciBtbGVwaW5za2ku aWV0ZkBnbWFpbC5jb20pDQoNClRoaXMgRS1tYWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRz IG1heSBjb250YWluIFRpbWUgV2FybmVyIENhYmxlIHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3 aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9yIHN1YmplY3QgdG8gY29weXJpZ2h0 IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5kZWQg c29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBp dCBpcyBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2Yg dGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRp b24sIGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRha2VuIGluIHJlbGF0aW9uIHRv IHRoZSBjb250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8gdGhpcyBFLW1haWwgaXMgc3RyaWN0 bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5 IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbnkgY29weSBvZiB0aGlz IEUtbWFpbCBhbmQgYW55IHByaW50b3V0Lg0K From repenno@cisco.com Wed Jul 25 13:38:24 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A50F421F86FA for ; Wed, 25 Jul 2012 13:38: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=[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 EZYjWu1nMFdL for ; Wed, 25 Jul 2012 13:38:23 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 8A4F021F86E5 for ; Wed, 25 Jul 2012 13:38:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=repenno@cisco.com; l=11571; q=dns/txt; s=iport; t=1343248703; x=1344458303; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=mY6wvYeW08mtO6MJgju/WQGUdEI2VThiG7AYDGXtbAo=; b=DMpJtEoEJVkz2hRzV/q5x2b0A5QE+p7qUpXR1yhLMOTCjiuj+IM5Hwk3 s4JTdtB/Mf2kR7aQ4gvhsYG/8vTARIvOzlsMYmL9N7l/vK/Ji0aghau2A f0+AWQcMn5/IF0EbmbhMkIt8CBG0Y2CBk68y0ZFY6utx6WC2Nz7U4y8pv g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYHADBYEFCtJV2d/2dsb2JhbABFgkqmBIgOAYhwgQeCIAEBAQQBAQEPARpBBBkBGQMBAiguCxQJCAIEARIJEgeHawubMaBKi00ahloDlUmBFIl5gxqBZoJfgV8 X-IronPort-AV: E=Sophos;i="4.77,654,1336348800"; d="scan'208,217";a="105322299" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 25 Jul 2012 20:38:23 +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 q6PKcMVs032663 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Jul 2012 20:38:22 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; Wed, 25 Jul 2012 15:38:22 -0500 From: "Reinaldo Penno (repenno)" To: "George, Wes" , "sunset4@ietf.org" Thread-Topic: Agenda Request Thread-Index: AQHNaqVumO7B2D5QakinweDKwSSj0g== Date: Wed, 25 Jul 2012 20:38:21 +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.89.8.145] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19064.001 x-tm-as-result: No--39.455900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_CC35A6798252repennociscocom_" MIME-Version: 1.0 Subject: [sunset4] Agenda Request X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 20:38:24 -0000 --_000_CC35A6798252repennociscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable http://tools.ietf.org/html/draft-penno-behave-rfc4787-5382-5508-bis-03 1) describe the problem to be solved and show that there is widespread demand for a solution The draft proposes important fixes for all types of NAT44 (CGN or not) 2) demonstrate that the problem can not be solved with existing Technologies This draft does not propose any new transition technology or NAT type, just= improvements to existing NAT44/CGN 3) provide a description of the proposed solution along with its impact on current IPv4-only use and justification that it does not har= m or delay the deployment of IPv6 It does not harm or delay IPv6 deployment since it does not propose any new= technology. From: "George, Wes" > Date: Wed, 25 Jul 2012 09:40:17 -0400 To: "sunset4@ietf.org" > Subject: [sunset4] Updates to Sunset4 charter All =96 The ADs, Marc, and I have been working on some relatively minor updates to = the charter to fix some of the confusion and contradiction that existed in = the first version. These are changes we made after a good bit of discussion= with many of the ADs and WG chairs involved about the purpose of the WG an= d the division of work between ours and other WGs that may have overlap. Or= iginally, the plan was to have these changes approved prior to the meeting = so that a new version was posted, but IESG has decided that they would like= the WG to review them and come to consensus in Vancouver, and then it will= go back to IESG for approval. I wanted to give people time to read the cha= rter before the meeting so that we can get substantive comments, either on = list or in the meeting, and start making forward progress on the actual wor= k that this group should be undertaking. Here is a link to the current charter: http://datatracker.ietf.org/wg/sunse= t4/charter/ Here is a link to the proposed charter: http://www.ietf.org/proceedings/84/= slides/slides-84-sunset4-0.txt And a link to the diff: http://www.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1= =3Dhttp://www.ietf.org/charter/charter-ietf-sunset4-01.txt&url2=3Dhttp://ww= w.ietf.org/proceedings/84/slides/slides-84-sunset4-0.txt or http://tinyurl.= com/clr435p 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. _______________________________________________ sunset4 mailing list sunset= 4@ietf.org https://www.ietf.org/mailman/listinfo/s= unset4 --_000_CC35A6798252repennociscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable 
http://tools.=
ietf.org/html/draft-penno-behave-rfc4787-5382-5508-bis-03

  1) describe=
 the problem to be solved and show that there is widespread
     demand for a solution

The draft pro=
poses important fixes for all types of NAT44 (CGN or not)

  2) demonstr=
ate that the problem can not be solved with existing
     Technologies

This draft do=
es not propose any new transition technology or NAT type, just improvements=
 to existing NAT44/CGN
  3) provide a description of the proposed solution along with its
     impact on current IPv4-only use and justification that it does not har=
m or delay the deployment of IPv6

It does not harm or delay IPv6 deployment since it does not propose an= y new technology. 


From: "George, Wes" <<= a href=3D"mailto:wesley.george@twcable.com">wesley.george@twcable.com&g= t;
Date: Wed, 25 Jul 2012 09:40:17 -04= 00
To: "sunset4@ietf.org" <sunset4@ietf.org>
Subject: [sunset4] Updates to Sunse= t4 charter

All =96

 

The ADs, Marc, and I have been working on some relat= ively minor updates to the charter to fix some of the confusion and contrad= iction that existed in the first version. These are changes we made after a= good bit of discussion with many of the ADs and WG chairs involved about the purpose of the WG and the divi= sion of work between ours and other WGs that may have overlap. Originally, = the plan was to have these changes approved prior to the meeting so that a = new version was posted, but IESG has decided that they would like the WG to review them and come to consens= us in Vancouver, and then it will go back to IESG for approval. I wanted to= give people time to read the charter before the meeting so that we can get= substantive comments, either on list or in the meeting, and start making forward progress on the actual wo= rk that this group should be undertaking.

 

Here is a link to the current charter: http://datatracker.ietf.org/wg/sunset4/charter/

 

Here is a link to the proposed charter: http://www.ietf.org/proceedings/84/slides/slides-84-sunset4-0.txt<= /o:p>

 

And a link to the diff: http://www.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=3Dhttp://www.ietf.org/c= harter/charter-ietf-sunset4-01.txt&url2=3Dhttp://www.ietf.org/proceedin= gs/84/slides/slides-84-sunset4-0.txt or http://tinyurl.com/clr435p<= /o:p>

 

Thanks,

 

Wes George

 


This E-mail and any of its a= ttachments may contain Time Warner Cable proprietary information, which is = privileged, confidential, or subject to copyright belonging to Time Warner = Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.
_______________________________________________ sunset4 mailing list sunset4@ietf.org https://www.ietf.org/mailman/listinfo/sunset4
--_000_CC35A6798252repennociscocom_-- From wesley.george@twcable.com Fri Jul 27 14:05:55 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA86F11E808A for ; Fri, 27 Jul 2012 14:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.521 X-Spam-Level: X-Spam-Status: No, score=-0.521 tagged_above=-999 required=5 tests=[AWL=-0.058, 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 UOsfci1hmRyH for ; Fri, 27 Jul 2012 14:05:55 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id DCC5E21F8463 for ; Fri, 27 Jul 2012 14:05:54 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.77,669,1336363200"; d="scan'208";a="398652502" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 27 Jul 2012 17:05:45 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Fri, 27 Jul 2012 17:05:50 -0400 From: "George, Wes" To: Reinaldo Penno , "sunset4@ietf.org" Date: Fri, 27 Jul 2012 17:05:47 -0400 Thread-Topic: CGN document for consideration Thread-Index: Ac0n5gon3kbCiaUERKKQWfa6RmaDIBEVJl2Q Message-ID: References: In-Reply-To: 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 Subject: Re: [sunset4] CGN document for consideration X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 21:05:55 -0000 Reinaldo - A comment about this draft: In section 3.2, you mention immediate purge of mapping when a TCP RST is re= ceived. While it's not a unique issue to this recommendation, I think there= 's a security consideration around this - an attacker could cause a lot of = state-mapping churn on the CGN (in addition to the obvious impact to the cu= stomer session itself) by sending random TCP RSTs to ports on the external = IP address block of the CGN. Therefore it may not be advisable to recommend= this behavior without some sort of rate-limiting or a discussion of ways t= o distinguish legitimate TCP RSTs that do legitimately occur from malicious= ly initiated RSTs. Thanks, Wes George, speaking as an individual > -----Original Message----- > From: sunset4-bounces@ietf.org [mailto:sunset4-bounces@ietf.org] On > Behalf Of Reinaldo Penno > Sent: Tuesday, May 01, 2012 6:01 PM > To: sunset4@ietf.org > Subject: [sunset4] CGN document for consideration > > Hi, > > I would like to submit this document to the WG for consideration. > > http://tools.ietf.org/html/draft-penno-behave-rfc4787-5382-5508-bis-02 > > I'm assuming that port allocation method drafts should be submitted to > this WG. > > Thanks, > > Reinaldo > > > _______________________________________________ > sunset4 mailing list > sunset4@ietf.org > https://www.ietf.org/mailman/listinfo/sunset4 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 marc.blanchet@viagenie.ca Mon Jul 30 12:57:09 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E50BA11E815A for ; Mon, 30 Jul 2012 12:57:09 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXioq9KUGgsw for ; Mon, 30 Jul 2012 12:57:07 -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 EEC5211E81E6 for ; Mon, 30 Jul 2012 12:57:06 -0700 (PDT) Received: from [IPv6:2001:df8::80:ac0f:18cc:147:9d09] (unknown [IPv6:2001:df8:0:80:ac0f:18cc:147:9d09]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 6668541582 for ; Mon, 30 Jul 2012 15:57:06 -0400 (EDT) From: Marc Blanchet Content-Type: multipart/alternative; boundary="Apple-Mail=_58398919-117B-4E11-AF5C-F91C3BF26971" Date: Mon, 30 Jul 2012 12:57:04 -0700 Message-Id: <1BF217C8-2A2C-4017-A8B8-AB050E0355B9@viagenie.ca> To: sunset4@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [sunset4] meeting notes X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 19:57:10 -0000 --Apple-Mail=_58398919-117B-4E11-AF5C-F91C3BF26971 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello, We haven't found the IETF ether pad service so we will use another one = for minutes/notes taking: http://piratepad.net/sunset4 Please use it. Marc.= --Apple-Mail=_58398919-117B-4E11-AF5C-F91C3BF26971 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Please use = it.

Marc.
= --Apple-Mail=_58398919-117B-4E11-AF5C-F91C3BF26971-- From mcr+ietf@sandelman.ca Mon Jul 30 20:29:26 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBD2E11E80E5 for ; Mon, 30 Jul 2012 20:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.045 X-Spam-Level: X-Spam-Status: No, score=-2.045 tagged_above=-999 required=5 tests=[AWL=0.554, 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 EYyt9Sj2BC+j for ; Mon, 30 Jul 2012 20:29:25 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.252.184]) by ietfa.amsl.com (Postfix) with ESMTP id BFF3911E80E2 for ; Mon, 30 Jul 2012 20:29:25 -0700 (PDT) Received: from obiwan.sandelman.ca (unknown [IPv6:2607:f0b0:f:2:3a60:77ff:fe38:e647]) by tuna.sandelman.ca (Postfix) with ESMTP id 0DAF020168; Mon, 30 Jul 2012 23:41:42 -0400 (EDT) From: Michael Richardson To: sunset4@ietf.org X-Mailer: MH-E 8.3; nmh 1.5; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Cc: draft-dionne-sunset4-v4gapanalysis@tools.ietf.org Subject: [sunset4] question about problem 7 of draft-dionne-sunset4-v4gapanalysis-00 X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 03:29:26 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable > PROBLEM 7: Completely disabling IPv4 at runtime often reveals > implementation bugs. Hard-coded dependencies on IPv4 > abound, such as on the 127.0.0.1 address assigned to the > loopback interface. It is therefore often operationally > impossible to completely disable IPv4 on individual > nodes. given that lo0/127.0.0.1 data never leaves the host, it's pretty much of of scope for the IETF. Further, if we agree that one turns off IPv4 on a per-interface basis, then whether or not lo0 has IPv4 on or off isn't relevant to the external world. While I think that trying to build operating systems without IPv4 (and reporting any code savings) is a useful thing to do, I think it's out of scope. If 127.0.0.1 turns out to be hard coded somewhere *in a protocol*, that would be important to know. (As an aside a debian VM template that I've used way too much was missing turning on lo0. It mostly worked. NFS failed, and a few other things would fail, but surprising little, cause it would take me months to notice..) =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUBdREIqHRg3pndX9AQLyNAQA36QqSVxApoO7CWTkbzM3qZsiCyBlFBvk P6f8wEcBX/5CslSU+Xm7C+++1NQbdL8jpbm5OLxvclE+svvpt2wtAjp28680ywJ/ uQECih0u0+yF25PbDJyuxYXdgrAujGuwQIw6mFnHkVXdBein1npxai1oChheYHhE cDC4R+L8YVE= =qt3M -----END PGP SIGNATURE----- --=-=-=-- From simon.perreault@viagenie.ca Mon Jul 30 22:39:00 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C751611E80D2 for ; Mon, 30 Jul 2012 22:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.057, 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 N3ez+nN52hqq for ; Mon, 30 Jul 2012 22:39:00 -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 1C0B021F85DB for ; Mon, 30 Jul 2012 22:39:00 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2001:df8:0:64:d4f2:dfff:aecc:1f25]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 85DAD4036B for ; Tue, 31 Jul 2012 01:38:58 -0400 (EDT) Message-ID: <50176F70.2020509@viagenie.ca> Date: Mon, 30 Jul 2012 22:38:56 -0700 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0 MIME-Version: 1.0 To: sunset4@ietf.org References: <18274.1343705360@obiwan.sandelman.ca> In-Reply-To: <18274.1343705360@obiwan.sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [sunset4] question about problem 7 of draft-dionne-sunset4-v4gapanalysis-00 X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 05:39:00 -0000 Le 2012-07-30 20:29, Michael Richardson a écrit : > >> PROBLEM 7: Completely disabling IPv4 at runtime often reveals >> implementation bugs. Hard-coded dependencies on IPv4 >> abound, such as on the 127.0.0.1 address assigned to the >> loopback interface. It is therefore often operationally >> impossible to completely disable IPv4 on individual >> nodes. > > given that lo0/127.0.0.1 data never leaves the host, it's pretty much of > of scope for the IETF. If people want to turn off IPv4 on lo0, and they're unable to, then it's in scope for the IETF. The IETF created IPv4. We can at least acknowledge and document the problem. Maybe we can even do something about it, but I'm not too sure what at this point. Making it easier for people to disable it, even if it's on lo0, is very much IETF's burden. > Further, if we agree that one turns off IPv4 on > a per-interface basis, then whether or not lo0 has IPv4 on or off isn't > relevant to the external world. True. Note that we're not saying that people SHOULD turn off lo0. We're only saying that when people want to do that, they're hitting a wall. That's a real problem with a protocol that the IETF created. It may only be due to implementations. But it's still a real problem. Can we do something about it? I don't know yet. But there are people working on it. > (As an aside a debian VM template that I've used way too much was > missing turning on lo0. It mostly worked. NFS failed, and a few other > things would fail, but surprising little, cause it would take me months > to notice..) Super cool! :) One thing I immediately noticed when I removed 127.0.0.1 on Fedora 17 was that virtualization didn't work anymore. It turns out that libvirtd binds to 127.0.0.1 and I haven't found a way to change that. So when I need a VM I have to "ip addr add 127.0.0.1/8 dev lo" by hand... 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