From iesg-secretary@ietf.org Tue May 1 09:33:19 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 4B28921E8245; Tue, 1 May 2012 09:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d+bg-mxkxIZI; Tue, 1 May 2012 09:33:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABC0E21E816B; Tue, 1 May 2012 09:33:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120501163318.8925.56287.idtracker@ietfa.amsl.com> Date: Tue, 01 May 2012 09:33:18 -0700 Cc: marc.blanchet@viagenie.ca, sunset4@ietf.org, wesley.george@twcable.com Subject: [sunset4] WG Action: sunset4 (sunset4) 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, 01 May 2012 16:33:19 -0000 A new IETF working group has been formed in the Internet Area. For additio= nal information, please contact the Area Directors or the WG Chairs. sunset4 (sunset4) -------------------- Current Status: Active Chairs (proposed): Marc Blanchet Wes George INT Area Director: Ralph Droms Area Advisors: OPS: Fred Baker TSV: Martin Stiemerling RTG: Stewart Bryant Mailing Lists: Address: sunset4@ietf.org List Subscription: https://www.ietf.org/mailman/listinfo/sunset4 Email Archive: http://www.ietf.org/mail-archive/web/sunset4/ Description of Working Group: The IETF is committed to the deployment of IPv6 to ensure the evolution of the Internet. However, the IPv4-only components of the Internet must continue to operate as much as possible during the transition from IPv4 to IPv6. The Working Group will standardize technologies that facilitate the graceful sunsetting of the IPv4 Internet in the context of the exhaustion of IPv4 address space while IPv6 is deployed. These technologies will likely be less optimal than equivalent technologies for IPv6-only and dual-stack networks. The Working Group works only on IPv4 protocols to facilitate IPv4 sunsetting. The Working Group may work on fixing security bugs in existing IPv4-specific protocols but is not chartered to add new security functionality to those protocols. The working group will provide a single venue for the consideration of IPv4 sunsetting, while ensuring that any such technologies do not impede the deployment of IPv6 and do not duplicate functions and capabilities already available in existing technologies. Therefore, along the lines of draft-george-ipv6-support, before the working group adopts any technology, it must: 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 the impact on current IPv4-only use and its ability to promote the deployment of IPv6 = These steps will likely be described in the form of a use case and requirements document. Only after the above mentioned steps have been completed and the results accepted by the community will the IETF consider adding new work items to the Working Group charter. This new work may include protocol specifications. The work spans over multiple IETF areas including as Internet, Operations, Transport and Routing. Therefore, cross-area coordination and support is essential and required. Any work on IPv4 to IPv6 transition methods is out of scope. The initial work items are: * Review current Carrier-Grade NAT (CGN) documents and related issues, including requirements for standardization, and determine if CGN is a suitable sunsetting technology to become a work item: draft-ietf-behave-lsn-requirements draft-ietf-behave-nat-mib CGN port allocation methods * Gap analysis of IPv4 features to facilitate IPv4 sunsetting Milestones 2012-09 Complete review of CGN and, if necessary, propose CGN work items 2013-06 Send gap analysis on IPv4 sunsetting to IESG From rdroms.ietf@gmail.com Tue May 1 10:42:08 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 06C0521E8252; Tue, 1 May 2012 10:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.349 X-Spam-Level: X-Spam-Status: No, score=-103.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PRAwwr2mjdYK; Tue, 1 May 2012 10:42:07 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C7D1221E8050; Tue, 1 May 2012 10:42:03 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so3408089vbb.31 for ; Tue, 01 May 2012 10:42:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=0XhVp5Yzc7A5Ff3LJ/1TCowtXmntuaVggLbuMgubIgA=; b=f7Y+upwqdh0zjQ2pscsepWjygAC8jvu1F6dM0eVHJc0RREWIKmXMLOHUuI9uZqpdXb ztsoGaACdQIx1cwkdmonVHaayL/9x7+sYKpw5b6TmOL1+E7G7zDzK4KegHV/q4Wb4qsT ApmuvHxhkwb41owHYtWr5rVHV+JyxZD8RSEluNg+EucvJXknCgwPu2hUM3gY6Qx1Km3r U825F+cTmCHVg+/tva5sdrjMQZVPO9ImQ7kixJNXDn7GGL7YYlwYOQ2rOnf9QaUfJGoV uFeRqeVbwc1RzfGqnH0Qm9819n7Q96P7R7Ha3eOSpjMaqW4s44IkdgNWy5CcVAKQD0F3 Nlqg== Received: by 10.52.68.204 with SMTP id y12mr22340571vdt.53.1335894123333; Tue, 01 May 2012 10:42:03 -0700 (PDT) Received: from [161.44.65.173] ([161.44.65.173]) by mx.google.com with ESMTPS id jz16sm33100157vdb.9.2012.05.01.10.42.01 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 01 May 2012 10:42:02 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: <20120501163318.8925.56287.idtracker@ietfa.amsl.com> Date: Tue, 1 May 2012 13:42:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <04119FB5-617B-41C5-BB89-51617669A72E@gmail.com> References: <20120501163318.8925.56287.idtracker@ietfa.amsl.com> To: IETF Announcement List X-Mailer: Apple Mail (2.1257) Cc: Marc Blanchet , IESG Secretary , Wes George , sunset4@ietf.org Subject: Re: [sunset4] WG Action: sunset4 (sunset4) 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, 01 May 2012 17:42:08 -0000 Minor update to the published charter: Marc and Wes are confirmed as WG = chairs (not "proposed"). Thanks to both Marc and Wes for taking on the = leadership of sunset4. - Ralph On May 1, 2012, at 12:33 PM 5/1/12, IESG Secretary wrote: > A new IETF working group has been formed in the Internet Area. For = additional information, please contact the Area Directors or the WG = Chairs. >=20 > sunset4 (sunset4) > -------------------- > Current Status: Active >=20 > Chairs (proposed): > Marc Blanchet > Wes George >=20 > INT Area Director: > Ralph Droms >=20 > Area Advisors: > OPS: Fred Baker > TSV: Martin Stiemerling > RTG: Stewart Bryant >=20 > Mailing Lists: > Address: sunset4@ietf.org > List Subscription: https://www.ietf.org/mailman/listinfo/sunset4 > Email Archive: http://www.ietf.org/mail-archive/web/sunset4/ >=20 > Description of Working Group: >=20 > The IETF is committed to the deployment of IPv6 to ensure the > evolution of the Internet. However, the IPv4-only components of the > Internet must continue to operate as much as possible during the > transition from IPv4 to IPv6. >=20 > The Working Group will standardize technologies that facilitate the > graceful sunsetting of the IPv4 Internet in the context of the > exhaustion of IPv4 address space while IPv6 is deployed. These > technologies will likely be less optimal than equivalent technologies > for IPv6-only and dual-stack networks. The Working Group works only > on IPv4 protocols to facilitate IPv4 sunsetting. >=20 > The Working Group may work on fixing security bugs in existing > IPv4-specific protocols but is not chartered to add new security > functionality to those protocols. >=20 > The working group will provide a single venue for the consideration of > IPv4 sunsetting, while ensuring that any such technologies do not > impede the deployment of IPv6 and do not duplicate functions and > capabilities already available in existing technologies. Therefore, > along the lines of draft-george-ipv6-support, before the working > group adopts any technology, it must: >=20 > 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 the > impact on current IPv4-only use and its ability to promote the > deployment of IPv6=20 >=20 > These steps will likely be described in the form of a use case and > requirements document. >=20 > Only after the above mentioned steps have been completed and the > results accepted by the community will the IETF consider adding new > work items to the Working Group charter. This new work may include > protocol specifications. >=20 > The work spans over multiple IETF areas including as Internet, > Operations, Transport and Routing. Therefore, cross-area coordination > and support is essential and required. Any work on IPv4 to IPv6 > transition methods is out of scope. >=20 > The initial work items are: >=20 > * Review current Carrier-Grade NAT (CGN) documents and related issues, > including requirements for standardization, and determine if CGN is > a suitable sunsetting technology to become a work item: > draft-ietf-behave-lsn-requirements > draft-ietf-behave-nat-mib > CGN port allocation methods > * Gap analysis of IPv4 features to facilitate IPv4 sunsetting >=20 > Milestones >=20 > 2012-09 Complete review of CGN and, if necessary, propose CGN work > items > 2013-06 Send gap analysis on IPv4 sunsetting to IESG >=20 >=20 > _______________________________________________ > sunset4 mailing list > sunset4@ietf.org > https://www.ietf.org/mailman/listinfo/sunset4 From iesg-secretary@ietf.org Tue May 1 10:46:30 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 1C9D221E8301; Tue, 1 May 2012 10:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KlH23g+zUE+4; Tue, 1 May 2012 10:46:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4513721E803C; Tue, 1 May 2012 10:46:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120501174626.28525.9916.idtracker@ietfa.amsl.com> Date: Tue, 01 May 2012 10:46:26 -0700 Cc: sunset4@ietf.org Subject: [sunset4] CORRECTED WG Action: sunset4 (sunset4) 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, 01 May 2012 17:46:30 -0000 Minor update to the published charter: Marc and Wes are confirmed as WG cha= irs (not "proposed"). Thanks to both Marc and Wes for taking on the leaders= hip of sunset4. - Ralph On May 1, 2012, at 12:33 PM 5/1/12, IESG Secretary wrote: > A new IETF working group has been formed in the Internet Area. For additi= onal information, please contact the Area Directors or the WG Chairs. > > sunset4 (sunset4) > -------------------- > Current Status: Active > > Chairs: > Marc Blanchet > Wes George > > INT Area Director: > Ralph Droms > > Area Advisors: > OPS: Fred Baker > TSV: Martin Stiemerling > RTG: Stewart Bryant > > Mailing Lists: > Address: sunset4@ietf.org > List Subscription: https://www.ietf.org/mailman/listinfo/sunset4 > Email Archive: http://www.ietf.org/mail-archive/web/sunset4/ > > Description of Working Group: > > The IETF is committed to the deployment of IPv6 to ensure the > evolution of the Internet. However, the IPv4-only components of the > Internet must continue to operate as much as possible during the > transition from IPv4 to IPv6. > > The Working Group will standardize technologies that facilitate the > graceful sunsetting of the IPv4 Internet in the context of the > exhaustion of IPv4 address space while IPv6 is deployed. These > technologies will likely be less optimal than equivalent technologies > for IPv6-only and dual-stack networks. The Working Group works only > on IPv4 protocols to facilitate IPv4 sunsetting. > > The Working Group may work on fixing security bugs in existing > IPv4-specific protocols but is not chartered to add new security > functionality to those protocols. > > The working group will provide a single venue for the consideration of > IPv4 sunsetting, while ensuring that any such technologies do not > impede the deployment of IPv6 and do not duplicate functions and > capabilities already available in existing technologies. Therefore, > along the lines of draft-george-ipv6-support, before the working > group adopts any technology, it must: > > 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 the > impact on current IPv4-only use and its ability to promote the > deployment of IPv6 > > These steps will likely be described in the form of a use case and > requirements document. > > Only after the above mentioned steps have been completed and the > results accepted by the community will the IETF consider adding new > work items to the Working Group charter. This new work may include > protocol specifications. > > The work spans over multiple IETF areas including as Internet, > Operations, Transport and Routing. Therefore, cross-area coordination > and support is essential and required. Any work on IPv4 to IPv6 > transition methods is out of scope. > > The initial work items are: > > * Review current Carrier-Grade NAT (CGN) documents and related issues, > including requirements for standardization, and determine if CGN is > a suitable sunsetting technology to become a work item: > draft-ietf-behave-lsn-requirements > draft-ietf-behave-nat-mib > CGN port allocation methods > * Gap analysis of IPv4 features to facilitate IPv4 sunsetting > > Milestones > > 2012-09 Complete review of CGN and, if necessary, propose CGN work > items > 2013-06 Send gap analysis on IPv4 sunsetting to IESG From repenno@cisco.com Tue May 1 15:01:22 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 BA69C21E80F0 for ; Tue, 1 May 2012 15:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.714 X-Spam-Level: X-Spam-Status: No, score=-9.714 tagged_above=-999 required=5 tests=[AWL=0.885, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EkFUb6wbGr8k for ; Tue, 1 May 2012 15:01:22 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB6021E80DB for ; Tue, 1 May 2012 15:01:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=repenno@cisco.com; l=255; q=dns/txt; s=iport; t=1335909682; x=1337119282; h=date:subject:from:to:message-id:mime-version: content-transfer-encoding; bh=dN6rUmSr3GvZWAS2v0jFjJYc5zILwkq4T9N1kcLUJ9c=; b=OpsDX8LugZ85ABwdaKegDIinOs36hvWrVUsXs8vEXhRUM4/ikP5YAHfI C8WxXCpdZCl+SRIqnynHyFmyWvB2ANIIMIQII1NVCamPhH8ShzAlJNiPF +rgg0n7fArxYNNxOZ1DrlKQpxhXwFocSW4A/W5hZPVE0yQqq2v27NLGtJ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnUHAMJcoE+rRDoG/2dsb2JhbABEgx0GrFaDAYEHghASAScCAU+BKzWHagyZCIEonziNZIMlBIhkjRqBEYRliGOBaYMI X-IronPort-AV: E=Sophos;i="4.75,512,1330905600"; d="scan'208";a="39928519" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 01 May 2012 22:01:21 +0000 Received: from [10.21.114.209] (sjc-vpn2-721.cisco.com [10.21.114.209]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q41M1Cca012194 for ; Tue, 1 May 2012 22:01:20 GMT User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Tue, 01 May 2012 15:01:10 -0700 From: Reinaldo Penno To: Message-ID: Thread-Topic: CGN document for consideration Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [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: Tue, 01 May 2012 22:01:22 -0000 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 From marc.blanchet@viagenie.ca Tue May 1 15:44:30 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 B547221E8055 for ; Tue, 1 May 2012 15:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.676 X-Spam-Level: X-Spam-Status: No, score=-102.676 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TNKi+mWi+Q-3 for ; Tue, 1 May 2012 15:44:30 -0700 (PDT) Received: from blues.viagenie.ca (blues.viagenie.ca [66.228.45.110]) by ietfa.amsl.com (Postfix) with ESMTP id 1E7EB21E8050 for ; Tue, 1 May 2012 15:44:30 -0700 (PDT) Received: from [192.168.1.190] (modemcable180.211-203-24.mc.videotron.ca [24.203.211.180]) by blues.viagenie.ca (Postfix) with ESMTPSA id D89E41C281; Tue, 1 May 2012 18:44:28 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_10AD98DE-D1D3-4597-BDDC-DD49F4D1D14C" From: Marc Blanchet In-Reply-To: Date: Tue, 1 May 2012 18:44:27 -0400 Message-Id: References: To: Reinaldo Penno X-Mailer: Apple Mail (2.1257) Cc: sunset4@ietf.org 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: Tue, 01 May 2012 22:44:30 -0000 --Apple-Mail=_10AD98DE-D1D3-4597-BDDC-DD49F4D1D14C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 the current charter milestones are: 1) Review current Carrier-Grade NAT (CGN) documents =85 determine if CGN = is=20 a suitable sunsetting technology to become a work item... 2) Gap analysis of IPv4 features to facilitate IPv4 sunsetting Your document says: " This document focuses solely on NAPT44=85" How do you see your document fulfilling milestone 1 or 2 ? Marc. Le 2012-05-01 =E0 18:01, Reinaldo Penno a =E9crit : > Hi, >=20 > I would like to submit this document to the WG for consideration. >=20 > http://tools.ietf.org/html/draft-penno-behave-rfc4787-5382-5508-bis-02 >=20 > I'm assuming that port allocation method drafts should be submitted to > this WG. >=20 > Thanks, >=20 > Reinaldo >=20 >=20 > _______________________________________________ > sunset4 mailing list > sunset4@ietf.org > https://www.ietf.org/mailman/listinfo/sunset4 --Apple-Mail=_10AD98DE-D1D3-4597-BDDC-DD49F4D1D14C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 the = current charter milestones are:
1) Review current Carrier-Grade = NAT (CGN) documents =85 determine if CGN is 
a suitable = sunsetting technology to become a work item...
2) Gap analysis of IPv4 features to facilitate IPv4 = sunsetting

Your document says: " This document focuses solely on = NAPT44=85"

How do you see your document fulfilling milestone 1 or 2 = ?

Marc.

Le 2012-05-01 =E0 = 18:01, Reinaldo Penno a =E9crit :

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<= br>

= --Apple-Mail=_10AD98DE-D1D3-4597-BDDC-DD49F4D1D14C-- From repenno@cisco.com Tue May 1 16:27: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 191D821E80C7 for ; Tue, 1 May 2012 16:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.237 X-Spam-Level: X-Spam-Status: No, score=-9.237 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQmucoDTSQwp for ; Tue, 1 May 2012 16:27:21 -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 C011C21E8086 for ; Tue, 1 May 2012 16:27:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=repenno@cisco.com; l=6680; q=dns/txt; s=iport; t=1335914841; x=1337124441; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=zCf1+VF1tpFDh969256Pp5lTWjTk7QGyf5LfG7mcOgI=; b=PjRj10j6DCxApmt/fLceKw0XzczaLmwX+BSn/8S+V3iplh6oipUM9FSK dkJQeLaiRc1k7TEKk6E8j44/noKI+Nt9kgEXMXhTI1CuqAFqzwTaNOAyp Ipr1gzfZeKsiGkM4vWM5Jaqv6HKru6u5/rcQ24xgxIhn0sUj0ehGdwIMV o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtQGAPFwoE+rRDoJ/2dsb2JhbABEgkZXpgcBhlaBe4EGgQeCCQEBAQMBAQEBDwEqKgcLBQ4IEQMBAlYoCAYOBSKHZgQMmjufPJEJBIgwNI0agRGEZYhjgWmDCA X-IronPort-AV: E=Sophos;i="4.75,513,1330905600"; d="scan'208,217";a="40478221" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 01 May 2012 23:27:19 +0000 Received: from [10.21.114.209] (sjc-vpn2-721.cisco.com [10.21.114.209]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q41NR7w5017747; Tue, 1 May 2012 23:27:18 GMT User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Tue, 01 May 2012 16:27:02 -0700 From: Reinaldo Penno To: Marc Blanchet Message-ID: Thread-Topic: [sunset4] CGN document for consideration In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3418734438_5466785" Cc: sunset4@ietf.org 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: Tue, 01 May 2012 23:27:23 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3418734438_5466785 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Marc, A CGN is a NAPT44 which shares IP address across subscribers. It is fundamentally NAPT44. Thanks, Reinaldo From: Marc Blanchet Date: Tue, 1 May 2012 18:44:27 -0400 To: Reinaldo Penno Cc: Subject: Re: [sunset4] CGN document for consideration > the current charter milestones are: > 1) Review current Carrier-Grade NAT (CGN) documents =8A determine if CGN is > a suitable sunsetting technology to become a work item... > 2) Gap analysis of IPv4 features to facilitate IPv4 sunsetting >=20 > Your document says: " This document focuses solely on NAPT44=8A" >=20 > How do you see your document fulfilling milestone 1 or 2 ? >=20 > Marc. >=20 > Le 2012-05-01 =E0 18:01, Reinaldo Penno a =E9crit : >=20 >> Hi, >>=20 >> I would like to submit this document to the WG for consideration. >>=20 >> http://tools.ietf.org/html/draft-penno-behave-rfc4787-5382-5508-bis-02 >>=20 >> I'm assuming that port allocation method drafts should be submitted to >> this WG. >>=20 >> Thanks, >>=20 >> Reinaldo >>=20 >>=20 >> _______________________________________________ >> sunset4 mailing list >> sunset4@ietf.org >> https://www.ietf.org/mailman/listinfo/sunset4 >=20 --B_3418734438_5466785 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Hi Marc,

A CGN is a NAPT44 which shares IP address across subscribers. It is fu= ndamentally NAPT44. 

Thanks,

Reinaldo

From: Marc Blanchet <marc.blanche= t@viagenie.ca>
Date: Tue, 1= May 2012 18:44:27 -0400
To: Reina= ldo Penno <repenno@cisco.com>Cc: <sunset4@ietf.org>
Subject: <= /span> Re: [sunset4] CGN document for consideration

=
1) Review current Carrier-Grade NAT (CGN) documents …= ; determine if CGN is 
a suitable sunsetting technology to beco= me a work item...
2) Gap analysis of IPv4 features to facilitate IPv4 sunsetting

Your document says: " This document= focuses solely on NAPT44…"

How do you see your document fulfilling milestone 1 or 2 ?<= /div>

Marc.

<= div>Le 2012-05-01 =E0 18:01, Reinaldo Penno a =E9crit :

Hi,

I would like to s= ubmit this document to the WG for consideration.

http://tools.ie= tf.org/html/draft-penno-behave-rfc4787-5382-5508-bis-02

I'm assum= ing that port allocation method drafts should be submitted to
this WG.
Thanks,

Reinaldo


____________________________________= ___________
sunset4 mailing list
sun= set4@ietf.org
https://www.ietf.org/mailman/listinfo/sunset4

 --B_3418734438_5466785-- From marc.blanchet@viagenie.ca Tue May 1 17:19:32 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 6B62A21E8086 for ; Tue, 1 May 2012 17:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.669 X-Spam-Level: X-Spam-Status: No, score=-102.669 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGZezpyWUbP0 for ; Tue, 1 May 2012 17:19:31 -0700 (PDT) Received: from blues.viagenie.ca (blues.viagenie.ca [66.228.45.110]) by ietfa.amsl.com (Postfix) with ESMTP id 781B821E8020 for ; Tue, 1 May 2012 17:19:31 -0700 (PDT) Received: from [192.168.1.190] (modemcable180.211-203-24.mc.videotron.ca [24.203.211.180]) by blues.viagenie.ca (Postfix) with ESMTPSA id 534861C281; Tue, 1 May 2012 20:19:30 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_1821AAD3-F441-4552-8621-A0AD6CFC0330" From: Marc Blanchet In-Reply-To: Date: Tue, 1 May 2012 20:19:29 -0400 Message-Id: References: To: Reinaldo Penno X-Mailer: Apple Mail (2.1257) Cc: sunset4@ietf.org 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: Wed, 02 May 2012 00:19:32 -0000 --Apple-Mail=_1821AAD3-F441-4552-8621-A0AD6CFC0330 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Le 2012-05-01 =E0 19:27, Reinaldo Penno a =E9crit : > Hi Marc, >=20 > A CGN is a NAPT44 which shares IP address across subscribers. It is = fundamentally NAPT44.=20 yes, I know what it is =85 ;-) , but: as the charter says, we need to demonstrate/convince that CGN is an IPv4 = sunsetting technology, based on the following criteria: before the working group adopts any technology, it must:=20 1) describe the problem to be solved and show that there is widespread=20= demand for a solution=20 2) demonstrate that the problem can not be solved with existing=20 technologies=20 3) provide a description of the proposed solution along with the=20 impact on current IPv4-only use and its ability to promote the=20 deployment of IPv6=20 This is what the charter says. So before adopting CGN documents, we need to demonstrate that CGN is a = sunset4 technology. When demonstrated, then we can work on CGN/NAPT44 = topics. Right now, based on charter, we can't yet work on CGN/NAPT44. Marc. >=20 > Thanks, >=20 > Reinaldo >=20 > From: Marc Blanchet > Date: Tue, 1 May 2012 18:44:27 -0400 > To: Reinaldo Penno > Cc: > Subject: Re: [sunset4] CGN document for consideration >=20 >> the current charter milestones are: >> 1) Review current Carrier-Grade NAT (CGN) documents =85 determine if = CGN is=20 >> a suitable sunsetting technology to become a work item... >> 2) Gap analysis of IPv4 features to facilitate IPv4 sunsetting >>=20 >> Your document says: " This document focuses solely on NAPT44=85" >>=20 >> How do you see your document fulfilling milestone 1 or 2 ? >>=20 >> Marc. >>=20 >> Le 2012-05-01 =E0 18:01, Reinaldo Penno a =E9crit : >>=20 >>> Hi, >>>=20 >>> I would like to submit this document to the WG for consideration. >>>=20 >>> = http://tools.ietf.org/html/draft-penno-behave-rfc4787-5382-5508-bis-02 >>>=20 >>> I'm assuming that port allocation method drafts should be submitted = to >>> this WG. >>>=20 >>> Thanks, >>>=20 >>> Reinaldo >>>=20 >>>=20 >>> _______________________________________________ >>> sunset4 mailing list >>> sunset4@ietf.org >>> https://www.ietf.org/mailman/listinfo/sunset4 >>=20 > _______________________________________________ > sunset4 mailing list > sunset4@ietf.org > https://www.ietf.org/mailman/listinfo/sunset4 --Apple-Mail=_1821AAD3-F441-4552-8621-A0AD6CFC0330 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hi = Marc,

A CGN is a NAPT44 which shares IP address = across subscribers. It is fundamentally = NAPT44. 

yes, I know = what it is =85 ;-) , but:

as the charter says, = we need to demonstrate/convince that CGN is an IPv4 sunsetting = technology, based on the following criteria:

before the working  group adopts any technology, it = must: 

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 the 
impact on current IPv4-only = use and its ability to promote the 
deployment of = IPv6 
</charter_extract>

This is what the charter says.

So = before adopting CGN documents, we need to demonstrate that CGN is a = sunset4 technology. When demonstrated, then we can work on CGN/NAPT44 = topics.  Right now, based on charter, we can't yet work on = CGN/NAPT44.

Marc.


From: Marc Blanchet <marc.blanchet@viagenie.ca>= ;
Date: Tue, 1 May 2012 = 18:44:27 -0400
To: Reinaldo = Penno <repenno@cisco.com>
Cc: <sunset4@ietf.org>
Subject: Re: [sunset4] CGN document = for consideration

the current charter milestones = are:
1) Review current Carrier-Grade NAT (CGN) documents = =85 determine if CGN is 
a suitable sunsetting technology = to become a work item...
2) Gap analysis = of IPv4 features to facilitate IPv4 sunsetting

Your document says: " This document focuses solely on = NAPT44=85"

How do you see your document fulfilling milestone 1 or 2 = ?

Marc.

Le 2012-05-01 =E0 = 18:01, Reinaldo Penno a =E9crit :

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.or= g/mailman/listinfo/sunset4

_______________________________________________
sunset4 mailing = list
sunset4@ietf.org
https://www.ietf.= org/mailman/listinfo/sunset4

= --Apple-Mail=_1821AAD3-F441-4552-8621-A0AD6CFC0330-- From C.Donley@cablelabs.com Tue May 1 17:58:12 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 A058121E8094 for ; Tue, 1 May 2012 17:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.062 X-Spam-Level: X-Spam-Status: No, score=-0.062 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, 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 gMiyz4-amv5w for ; Tue, 1 May 2012 17:58:12 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 33C4A21E808B for ; Tue, 1 May 2012 17:58:12 -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 q420wAhZ020121 for ; Tue, 1 May 2012 18:58:10 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Tue, 01 May 2012 18:58:10 -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; Tue, 1 May 2012 18:58:11 -0600 From: Chris Donley To: "sunset4@ietf.org" Date: Tue, 1 May 2012 19:00:29 -0600 Thread-Topic: Deterministic CGN Thread-Index: Ac0n/qS6YZVlXqkjTm6+k1+wEOCazA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CBC5FF6D4F507cdonleycablelabscom_" MIME-Version: 1.0 X-Approved: ondar Subject: [sunset4] Deterministic CGN 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, 02 May 2012 00:58:12 -0000 --_000_CBC5FF6D4F507cdonleycablelabscom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I'd like to submit http://tools.ietf.org/html/draft-donley-behave-determini= stic-cgn-02 for working group adoption. It describes a problem with current= CGN technologies with respect to logging volumes and recommends an approac= h to reduce volumes by 6-7 orders of magnitude. As such, I think it fits wi= th both milestones defined in the sunset4 charter. We reviewed this draft in Paris, and v6ops recommended that I bring it to t= his group. Thanks, Chris --_000_CBC5FF6D4F507cdonleycablelabscom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello,

I'd like to submit http://tools.ietf.org/html/draft-= donley-behave-deterministic-cgn-02 for working group adoption. It desc= ribes a problem with current CGN technologies with respect to logging volum= es and recommends an approach to reduce volumes by 6-7 orders of magnitude.= As such, I think it fits with both milestones defined in the sunset4 chart= er.

We reviewed this draft in Paris, and v6ops rec= ommended that I bring it to this group.

Thanks,
Chris
--_000_CBC5FF6D4F507cdonleycablelabscom_-- From marc.blanchet@viagenie.ca Tue May 1 18:37: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 6E35721E8094 for ; Tue, 1 May 2012 18:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.363 X-Spam-Level: X-Spam-Status: No, score=-102.363 tagged_above=-999 required=5 tests=[AWL=-0.365, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 BQmKA5OmconU for ; Tue, 1 May 2012 18:37:29 -0700 (PDT) Received: from blues.viagenie.ca (blues.viagenie.ca [66.228.45.110]) by ietfa.amsl.com (Postfix) with ESMTP id B80B721E8013 for ; Tue, 1 May 2012 18:37:28 -0700 (PDT) Received: from [192.168.1.190] (modemcable180.211-203-24.mc.videotron.ca [24.203.211.180]) by blues.viagenie.ca (Postfix) with ESMTPSA id C11CF1C281; Tue, 1 May 2012 21:37:27 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_11FE04B3-FF54-418B-8F82-DBB488E4E43C" From: Marc Blanchet In-Reply-To: Date: Tue, 1 May 2012 21:37:27 -0400 Message-Id: <819239C8-C555-4B3D-B63C-8982250C3C4D@viagenie.ca> References: To: Chris Donley X-Mailer: Apple Mail (2.1257) Cc: "sunset4@ietf.org" Subject: Re: [sunset4] Deterministic CGN 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, 02 May 2012 01:37:29 -0000 --Apple-Mail=_11FE04B3-FF54-418B-8F82-DBB488E4E43C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Le 2012-05-01 =E0 21:00, Chris Donley a =E9crit : > Hello, >=20 > I'd like to submit = http://tools.ietf.org/html/draft-donley-behave-deterministic-cgn-02 for = working group adoption. It describes a problem with current CGN = technologies with respect to logging volumes and recommends an approach = to reduce volumes by 6-7 orders of magnitude. As such, I think it fits = with both milestones defined in the sunset4 charter. >=20 > We reviewed this draft in Paris, and v6ops recommended that I bring it = to this group. I understand that there are many documents that were waiting for a = working group home. I, for one, actually proposed to have milestones = such as CGN requirements, mob and port methods, as work items in the = sunset4 charter. But, at the end, we do have one more step _before_ we = can work on CGN. The additional step is described in the charter: * Review current Carrier-Grade NAT (CGN) documents ... and determine if = CGN is=20 a suitable sunsetting technology to become a work item=85 So we need to "review" the CGN documents and "determine if CGN is a = suitable IPv4 sunsetting technology, before it becomes a work item. So we need a document that convinces the IESG and the community that CGN = is an IPv4 sunsetting technology. Then we could have CGN work items. That is where we are with the group and the charter. Regards, Marc. >=20 > Thanks, > Chris > _______________________________________________ > sunset4 mailing list > sunset4@ietf.org > https://www.ietf.org/mailman/listinfo/sunset4 --Apple-Mail=_11FE04B3-FF54-418B-8F82-DBB488E4E43C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
http://tools.ietf.org/html/draft-donley-behave-deterministic-cgn-02=  for working group adoption. It describes a problem with current = CGN technologies with respect to logging volumes and recommends an = approach to reduce volumes by 6-7 orders of magnitude. As such, I think = it fits with both milestones defined in the sunset4 = charter.

We reviewed this draft in Paris, and = v6ops recommended that I bring it to this = group.

I = understand that there are many documents that were waiting for a working = group home. I, for one, actually proposed to have milestones such as CGN = requirements, mob and port methods, as work items in the sunset4 = charter. But, at the end, we do have one more step _before_ we can work = on CGN. The additional step is described in the = charter:

<charter_extract>
* Review current Carrier-Grade NAT (CGN) documents ... and = determine if CGN is 
a suitable sunsetting technology to become = a work item=85

So we need a document that convinces the = IESG and the community that CGN is an IPv4 sunsetting technology. =  Then we could have CGN work items.

That = is where we are with the group and the = charter.

Regards, = Marc.


Thanks,
Chris
_______________________________________________
sunset4 mailing = list
sunset4@ietf.org
https://www.ietf.= org/mailman/listinfo/sunset4

= --Apple-Mail=_11FE04B3-FF54-418B-8F82-DBB488E4E43C-- From brian.e.carpenter@gmail.com Wed May 2 03:00:42 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 714A721F8AF3 for ; Wed, 2 May 2012 03:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MuWPPb67-NVf for ; Wed, 2 May 2012 03:00:42 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id A6E4521F8AF4 for ; Wed, 2 May 2012 03:00:41 -0700 (PDT) Received: by eeke51 with SMTP id e51so121432eek.31 for ; Wed, 02 May 2012 03:00:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=/S0b4vb26TziWsEdwGEg04k+9oZF0uGbeORlqynn/sM=; b=hqekj0h/w/6px4ERXZoeNUyz6yysvUE17hzZ30Sh4t631AEMyh0yxJ0DEUtLfWixf9 nwUY34VEFvsWVzdRkKQxL/JOtIM5zIE4V50lkSCF5Jpspw4mT7RZWPmgrPb9JuZmBr8h 7Ah996k0CGniaG5yvYZAgzHqkQPQ/0Hpftbtjj6lbDBnB67hfLf0G3XKj96CForA7N6e YnjOCMUPNft/HL2oXCf5eBli2inwBYmcZb3nHlhYx1lU85OZPeAgNoJD+nHg8NMFDshr FLCR+6Y5XCcUwvV9uIXuZaQIva0HJrttLHx61jCvOpn1Tei56ggjYyIn+0zy3qY9Fi96 aWmA== Received: by 10.213.114.13 with SMTP id c13mr500050ebq.167.1335952840577; Wed, 02 May 2012 03:00:40 -0700 (PDT) Received: from [128.232.110.88] (c088.al.cl.cam.ac.uk. [128.232.110.88]) by mx.google.com with ESMTPS id y53sm6644998eea.3.2012.05.02.03.00.38 (version=SSLv3 cipher=OTHER); Wed, 02 May 2012 03:00:39 -0700 (PDT) Message-ID: <4FA105C3.2050403@gmail.com> Date: Wed, 02 May 2012 11:00:35 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Sunset IPv4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [sunset4] "determine if CGN is a suitable sunsetting technology" 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, 02 May 2012 10:00:42 -0000 I would suggest that RFC 6264 already discusses this point and implicitly describes a sunset model. It isn't explicit, because we weren't really trying to do that, but it certainly shows how CGN can take a carrier in that direction. However, this doesn't demonstrate a gap to be filled by new IPv4 work in this WG - it tends to show that for carriers, no new standards work is needed (if they choose to go the CGN route). It seems to me that the first work here should be to describe scenarios at subscriber, carrier and enterprise sites and then proceed to a gap analysis. That's what is needed to answer questions 1) and 2) in the charter, IMHO. Brian -- Regards Brian Carpenter From repenno@cisco.com Wed May 2 03:43: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 481E021F8A54 for ; Wed, 2 May 2012 03:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.928 X-Spam-Level: X-Spam-Status: No, score=-9.928 tagged_above=-999 required=5 tests=[AWL=0.671, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7GIDI7KHYG73 for ; Wed, 2 May 2012 03:43:47 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id A2C7D21F8A4C for ; Wed, 2 May 2012 03:43:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=repenno@cisco.com; l=1503; q=dns/txt; s=iport; t=1335955427; x=1337165027; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=hXnVAOOsETFfDmBa4wNuEDqn+Sx+BUg+/oDqB5p3Ssg=; b=VIqZCD+Iy9ygh3SAkDvIR426xJZL1bY5aNGvWT1yiETmB8gzkMtNhlGv nXU3vVX1wEaqDe24CtmLHJHBwXbijHeqPbPvYNWWlh+Czt1AptfUWQxE5 gOYOqqRTdjaPdnyXgsvu6l//Y7WVSCJjbOLvGh2RghknmT1R6D69eBfFt I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvUGADwPoU+rRDoI/2dsb2JhbABEgx6sWoMCgQeCCQEBAQMBAQEBDwEnAgEqBxAOCGcGMAYBEhsHh10DBgQMmjaWHA2JU4oGhwIEiGSNGoERhGWFSYMagWmDCA X-IronPort-AV: E=Sophos;i="4.75,515,1330905600"; d="scan'208";a="40033279" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 02 May 2012 10:43:47 +0000 Received: from [10.21.148.21] (sjc-vpn7-1045.cisco.com [10.21.148.21]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q42Ahjfc016763; Wed, 2 May 2012 10:43:46 GMT User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Wed, 02 May 2012 03:43:43 -0700 From: Reinaldo Penno To: Brian E Carpenter , Sunset IPv4 Message-ID: Thread-Topic: [sunset4] "determine if CGN is a suitable sunsetting technology" In-Reply-To: <4FA105C3.2050403@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [sunset4] "determine if CGN is a suitable sunsetting technology" 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, 02 May 2012 10:43:48 -0000 "1) describe the problem to be solved and show that there is widespread demand for a solution" On 5/2/12 3:00 AM, "Brian E Carpenter" wrote: >I would suggest that RFC 6264 already discusses this point >and implicitly describes a sunset model. It isn't explicit, >because we weren't really trying to do that, but it certainly >shows how CGN can take a carrier in that direction. > >However, this doesn't demonstrate a gap to be filled by new IPv4 >work in this WG - it tends to show that for carriers, no new >standards work is needed (if they choose to go the CGN route). I think there is a body of work related to CGN that shows standard work is needed. > >It seems to me that the first work here should be to describe >scenarios at subscriber, carrier and enterprise sites and then >proceed to a gap analysis. We already have your draft, http://tools.ietf.org/html/draft-kuarsingh-lsn-deployment-06 that deal with scenarios and others. We have mine with some other co-authors that show 'gaps' related to current implementations amongst others. Hopefully we can leverage much of that as we go through the 'gap and scenarios' motions. >That's what is needed to answer questions >1) and 2) in the charter, IMHO. > Brian > > > > > >-- >Regards > Brian Carpenter > > >_______________________________________________ >sunset4 mailing list >sunset4@ietf.org >https://www.ietf.org/mailman/listinfo/sunset4 From wesley.george@twcable.com Wed May 2 06:56: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 4C6C021F852C for ; Wed, 2 May 2012 06:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.405 X-Spam-Level: X-Spam-Status: No, score=-0.405 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 0qcLs46Zrg0U for ; Wed, 2 May 2012 06:56:01 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id A834421F8527 for ; Wed, 2 May 2012 06:56:01 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.75,516,1330923600"; d="scan'208";a="358939606" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 02 May 2012 09:55:00 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Wed, 2 May 2012 09:54:41 -0400 From: "George, Wes" To: Brian E Carpenter , Sunset IPv4 Date: Wed, 2 May 2012 09:54:39 -0400 Thread-Topic: [sunset4] "determine if CGN is a suitable sunsetting technology" Thread-Index: Ac0oSnPUozmUqKo6Tv+Vhtz+ghAfhgAHRTOQ Message-ID: References: <4FA105C3.2050403@gmail.com> In-Reply-To: <4FA105C3.2050403@gmail.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: Re: [sunset4] "determine if CGN is a suitable sunsetting technology" 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, 02 May 2012 13:56:02 -0000 > -----Original Message----- > From: sunset4-bounces@ietf.org [mailto:sunset4-bounces@ietf.org] On Behal= f Of > Brian E Carpenter > Sent: Wednesday, May 02, 2012 6:01 AM > To: Sunset IPv4 > Subject: [sunset4] "determine if CGN is a suitable sunsetting technology" > > I would suggest that RFC 6264 already discusses this point > and implicitly describes a sunset model. It isn't explicit, > because we weren't really trying to do that, but it certainly > shows how CGN can take a carrier in that direction. [WEG] Yes, but we all need to re-read it with the appropriate changes to ou= r prescription that this charter represents. It probably needs at least an = update via another draft or even a Bis doc. More on that below. > > However, this doesn't demonstrate a gap to be filled by new IPv4 > work in this WG - it tends to show that for carriers, no new > standards work is needed (if they choose to go the CGN route). [WEG] The two don't have to be joined in every case. I think that CGN is pr= obably one of those where those two items are not related because protocol = work is unnecessary. Protocol work necessary for IPv4 sunset is things like= new options in IPv4 protocols to handle the fact that they're being turned= off (responses to legacy devices with "sorry, not supported" etc) > > It seems to me that the first work here should be to describe > scenarios at subscriber, carrier and enterprise sites and then > proceed to a gap analysis. That's what is needed to answer questions > 1) and 2) in the charter, IMHO. > [WEG] I agree with Reinaldo that the Kuarsingh draft may help with that. It= 's also likely that we need to make some modifications to draft-ietf-behave= -lsn-requirements to absorb some lessons learned and more explicitly note t= he IPv4 sunset angle. That draft (or some other) may need to formally updat= e 6264, as I've always seen 6264's "IPv6 transition" as a bit of an afterth= ought - here's how you do CGN, and oh by the way, it's an IPv6 transition t= echnology in that it doesn't actively prevent IPv6. But then it recycles th= e standard set of methods to deploy IPv6 in a way that's almost wholly unre= lated to the specifics of CGN. I've already gone on record with the appropriate ADs as being a bit bothere= d by the language chosen in the charter regarding CGN as a sunsetting techn= ology because I think it's a difficult argument to make. How does deploying= CGN, by itself, advance IPv6 deployment? I don't have a good answer, but I= believe that our charter requires us to figure one out if we proceed with = standardizing CGN. I'm expecting some additional guidance on the matter from the associated AD= s, other WG chairs, etc in the coming weeks as we discuss how to transition= things from existing WGs, division of work, etc, so while this is good dis= cussion, we ask your patience while we figure this out in a way that helps = us to make forward progress on the charter items. I know there's a lot of u= nanswered questions. 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 j.schoenwaelder@jacobs-university.de Wed May 2 07:08:13 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 E686C21F85AF for ; Wed, 2 May 2012 07:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.162 X-Spam-Level: X-Spam-Status: No, score=-103.162 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8ih4jq2rrg8 for ; Wed, 2 May 2012 07:08:13 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4411B21F84F3 for ; Wed, 2 May 2012 07:08:13 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 17BB520CC3; Wed, 2 May 2012 16:08:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id E3Pcu2GQNTmu; Wed, 2 May 2012 16:08:11 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A727020CA9; Wed, 2 May 2012 16:08:11 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B58311EC7AAC; Wed, 2 May 2012 16:08:12 +0200 (CEST) Date: Wed, 2 May 2012 16:08:12 +0200 From: Juergen Schoenwaelder To: "George, Wes" Message-ID: <20120502140812.GA4783@elstar.local> Mail-Followup-To: "George, Wes" , Brian E Carpenter , Sunset IPv4 References: <4FA105C3.2050403@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Sunset IPv4 Subject: Re: [sunset4] "determine if CGN is a suitable sunsetting technology" X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 14:08:14 -0000 On Wed, May 02, 2012 at 09:54:39AM -0400, George, Wes wrote: > > However, this doesn't demonstrate a gap to be filled by new IPv4 > > work in this WG - it tends to show that for carriers, no new > > standards work is needed (if they choose to go the CGN route). > [WEG] The two don't have to be joined in every case. I think that > CGN is probably one of those where those two items are not related > because protocol work is unnecessary. I like to point out that there are no standard MIBs for monitoring boxes such as CGN. The MIB modules we have lack features. See for example here: http://tools.ietf.org/html/draft-schoenw-behave-nat-mib-bis-00 http://tools.ietf.org/html/draft-perreault-opsawg-natmib-bis-00 http://tools.ietf.org/html/draft-ietf-behave-nat-mib-00 The last one is mentioned in the sunset4 charter, not sure whether this means the intention is to move this document from behave to sunset4. Perhaps the intention was just to be undefined. ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From brian.e.carpenter@gmail.com Wed May 2 09:35:45 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 2E1F611E8093 for ; Wed, 2 May 2012 09:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.251 X-Spam-Level: X-Spam-Status: No, score=-101.251 tagged_above=-999 required=5 tests=[AWL=-0.160, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Hhik73k4+7I for ; Wed, 2 May 2012 09:35:44 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 362BF11E8088 for ; Wed, 2 May 2012 09:35:44 -0700 (PDT) Received: by eaaq11 with SMTP id q11so295490eaa.31 for ; Wed, 02 May 2012 09:35:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=808cIDtvODDCVpHi1znJSoFpd6cPIDn1WDaEtsyNDKA=; b=AFX+L2DIjixQ/rMnEoLZVf+gQVGTXwnr/IyPkDLJaTrIAbeAzk7+pTqbkIfZiMFY6y lG3FRXTmfAWG4ZVfNZCKEM0UNnLanSEIPst5kIuR8Vhtc+1edNeq291qQv+XUyVFI5XS 0d63JyyS9LxvTTZeTyviXkcErlP+AJycvz1OBClvd1GS1Zx1KAuZtF5XKNYIAlbIlNAU gFPwhXPUr240PyO7vyhsw2zWwGWkxNJ0vWL3ZM/W+XiI0JGJ0WCIzq6dLVgBqTOhBh77 kUYoUBhJgi154udBnb4A7YZi0MJ9zSKCYZPr8IteHGV4V7VmxAlQj347A9IDyDNcfEKH nvEA== Received: by 10.14.52.133 with SMTP id e5mr5747783eec.127.1335976543354; Wed, 02 May 2012 09:35:43 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-217-144.as13285.net. [2.102.217.144]) by mx.google.com with ESMTPS id r44sm11581608eef.2.2012.05.02.09.35.40 (version=SSLv3 cipher=OTHER); Wed, 02 May 2012 09:35:41 -0700 (PDT) Message-ID: <4FA16257.7030006@gmail.com> Date: Wed, 02 May 2012 17:35:35 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "George, Wes" References: <4FA105C3.2050403@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Sunset IPv4 Subject: Re: [sunset4] "determine if CGN is a suitable sunsetting technology" 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, 02 May 2012 16:35:45 -0000 Mainly agreed, comments in line: On 2012-05-02 14:54, George, Wes wrote: >> -----Original Message----- From: sunset4-bounces@ietf.org >> [mailto:sunset4-bounces@ietf.org] On Behalf Of Brian E >> Carpenter Sent: Wednesday, May 02, 2012 6:01 AM To: Sunset >> IPv4 Subject: [sunset4] "determine if CGN is a suitable >> sunsetting technology" >> >> I would suggest that RFC 6264 already discusses this point >> and implicitly describes a sunset model. It isn't explicit, >> because we weren't really trying to do that, but it >> certainly shows how CGN can take a carrier in that >> direction. > [WEG] Yes, but we all need to re-read it with the appropriate > changes to our prescription that this charter represents. It > probably needs at least an update via another draft or even a > Bis doc. More on that below. >> However, this doesn't demonstrate a gap to be filled by new >> IPv4 work in this WG - it tends to show that for carriers, >> no new standards work is needed (if they choose to go the >> CGN route). > [WEG] The two don't have to be joined in every case. I think > that CGN is probably one of those where those two items are > not related because protocol work is unnecessary. Protocol > work necessary for IPv4 sunset is things like new options in > IPv4 protocols to handle the fact that they're being turned > off (responses to legacy devices with "sorry, not supported" > etc) > >> It seems to me that the first work here should be to >> describe scenarios at subscriber, carrier and enterprise >> sites and then proceed to a gap analysis. That's what is >> needed to answer questions 1) and 2) in the charter, IMHO. >> > [WEG] I agree with Reinaldo that the Kuarsingh draft may help > with that. It's also likely that we need to make some > modifications to draft-ietf-behave-lsn-requirements to absorb > some lessons learned and more explicitly note the IPv4 sunset > angle. That draft (or some other) may need to formally update > 6264, as I've always seen 6264's "IPv6 transition" as a bit > of an afterthought - here's how you do CGN, and oh by the > way, it's an IPv6 transition technology in that it doesn't > actively prevent IPv6. I'm a bit disappointed that it can read that way. My frame of mind (and I believe my co-author's too) was: "Some carriers will insist on CGN. Let's document how that fits into an IPv6 transition strategy." We didn't spend much time on IPv6-only, because that really didn't seem like a fruitful discussion with major carriers for a number of years to come. > But then it recycles the standard set > of methods to deploy IPv6 in a way that's almost wholly > unrelated to the specifics of CGN. Absolutely, and that's the whole point. You can do CGN and do the IPv6 transition of your choice, simultaneously and on the same platform. No new protocol, which is why it was in the V6OPS charter - and exactly why I don't see it as needing more work here. > I've already gone on record with the appropriate ADs as being > a bit bothered by the language chosen in the charter > regarding CGN as a sunsetting technology because I think it's > a difficult argument to make. How does deploying CGN, by > itself, advance IPv6 deployment? I don't have a good answer, > but I believe that our charter requires us to figure one out > if we proceed with standardizing CGN. We may in fact be agreeing violently ;-). I see how NAT46 and 464XLAT might assist in v4 sunsetting, but those are quite different scenarios from CGN. Brian > > I'm expecting some additional guidance on the matter from the > associated ADs, other WG chairs, etc in the coming weeks as > we discuss how to transition things from existing WGs, > division of work, etc, so while this is good discussion, we > ask your patience while we figure this out in a way that > helps us to make forward progress on the charter items. I > know there's a lot of unanswered questions. > > Thanks Wes George From wesley.george@twcable.com Wed May 2 10:48: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 3470F21F85C0 for ; Wed, 2 May 2012 10:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.908 X-Spam-Level: X-Spam-Status: No, score=-0.908 tagged_above=-999 required=5 tests=[AWL=0.555, 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 pbEWemHArUB2 for ; Wed, 2 May 2012 10:48:06 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 8F81521F85C2 for ; Wed, 2 May 2012 10:48:06 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.75,518,1330923600"; d="scan'208";a="375710970" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 02 May 2012 13:45:56 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Wed, 2 May 2012 13:45:59 -0400 From: "George, Wes" To: Brian E Carpenter Date: Wed, 2 May 2012 13:46:00 -0400 Thread-Topic: [sunset4] "determine if CGN is a suitable sunsetting technology" Thread-Index: Ac0ogaIj4lIvAFZ4RVqjIghK/A0M0wAB5I7A Message-ID: References: <4FA105C3.2050403@gmail.com> <4FA16257.7030006@gmail.com> In-Reply-To: <4FA16257.7030006@gmail.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 Cc: Sunset IPv4 Subject: Re: [sunset4] "determine if CGN is a suitable sunsetting technology" 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, 02 May 2012 17:48:07 -0000 > > That draft (or some other) may need to formally update > > 6264, as I've always seen 6264's "IPv6 transition" as a bit > > of an afterthought - here's how you do CGN, and oh by the > > way, it's an IPv6 transition technology in that it doesn't > > actively prevent IPv6. > > I'm a bit disappointed that it can read that way. My frame of > mind (and I believe my co-author's too) was: "Some carriers will > insist on CGN. Let's document how that fits into an IPv6 > transition strategy." [WEG] Brian - I have no doubt that was your intent. I think what has happen= ed is that this is the only document that "standardizes" CGN thus far, beca= use CGN is more of a conceptual application of existing protocols and techn= ology than it is a new standard. As a result, 6264 is being viewed more as = a CGN document and less as a document that says "you can and should still d= o IPv6 even if you have to do CGN". Reopening the discussion gives us an op= portunity to put a finer point on it. 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 miya.kohno@gmail.com Tue May 8 00:19:30 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 D780E21F8458 for ; Tue, 8 May 2012 00:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 nmKlZAINPs1j for ; Tue, 8 May 2012 00:19:30 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0172921F8484 for ; Tue, 8 May 2012 00:19:26 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so270530wib.13 for ; Tue, 08 May 2012 00:19:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=SY0T4SgWhly9YI3m84o/d8yb/NrnZC5NL4D4u9JA7WI=; b=ma1wgOv15nY4Ky87A4ROa3K96g9gT7ZmLpEqhjRRrDYgb0qrTRGPXlg3Fuz386JfCM A1kSPhIatSwLktqKCb5/83/UT7r3+NWYL2X+CvWetqhIFMiIudy4VulYYYQqniilSUHY 4u/IVj/aDSUyncki9FCmo3t7f6+PuG8O55jEo23plAxM4GORoKG+HE7lWx+3Gp8ejXj+ 8A//4eI1cz8TplhF01Zi1ZLEJaAfdPTdiTtX8LtrAQspeMFooM9K4ZKQy+J4VOrUTM53 615MXhC9qKuZDRcKZejuF85g4+gYl4GepAl5Q6aJ/2/2lNI+G8fjD86yz6HpimwMkRGo 1EsA== MIME-Version: 1.0 Received: by 10.180.85.69 with SMTP id f5mr41960767wiz.18.1336461565871; Tue, 08 May 2012 00:19:25 -0700 (PDT) Received: by 10.223.60.198 with HTTP; Tue, 8 May 2012 00:19:25 -0700 (PDT) Date: Tue, 8 May 2012 16:19:25 +0900 Message-ID: From: Miya Kohno To: sunset4@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: marc.blanchet@viagenie.ca, wesley.george@twcable.com Subject: Re: [sunset4] WG Action: sunset4 (sunset4) 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, 08 May 2012 07:19:31 -0000 Hi, I have two comments to the WG. -------------- I. Clarification on the description. The description says "To facilitate the graceful sunsetting of the IPv4 Internet". Does this mean : 1) IETF is to promote the transition 2) Let the market decide the transition, and IETF is to minimize the disruption during the transition If 1), then we should aim more for migration. The solutions which have been coming up so far are rather for IPv4 life extension or IPv4/v6 co-existence, than for migration. However, 2) might be more practical. The lessons we have learnt are that we could not force nor promote the transition... And in that case, IPv4 life extension (address sharing by NAPT44) and IPv4/v6 co-existence (Encap/Tunnel/Translation) would make sense in terms of minimizing the disruption. -------------- II. Scope of work I'm afraid the works in this solution area so far tend to be scenario development, rather than protocol/function development. The consequence was the combinatorial explosion, wasn't it? For example, if the element technologies are { NAPT44 | Encap/Tunnel | Translation } and possible locations to put the functions are { host | CPE | GW@ xSP }, then it comes 2^(3+3) = 64! (Of course this didn't exclude impossible combination, but we have more variations (e.g. port allocation schemes for NAPT44), so it could be worse...) So I'm wondering if this WG could simplify the works and outcomes by sorting out the element technologies and the frameworks. Thanks, Miya From Tina.Tsou.Zouting@huawei.com Tue May 8 00:27:45 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 41F6E21F85D7 for ; Tue, 8 May 2012 00:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.127, 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 p0lBKCDaR7G2 for ; Tue, 8 May 2012 00:27:44 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0213721F84B8 for ; Tue, 8 May 2012 00:27:43 -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 AFX61428; Tue, 08 May 2012 03:27:43 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 8 May 2012 00:25:44 -0700 Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 8 May 2012 00:25:46 -0700 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.48]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.01.0323.003; Tue, 8 May 2012 15:25:39 +0800 From: Tina TSOU To: Miya Kohno Thread-Topic: [sunset4] WG Action: sunset4 (sunset4) Thread-Index: AQHNLOrxPnKksyE7k06cpR4DwXVoaZa/fbO3 Date: Tue, 8 May 2012 07:25:39 +0000 Message-ID: <8A1FF85B-C074-4393-B1DA-50C603A435F4@huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "marc.blanchet@viagenie.ca" , "wesley.george@twcable.com" , "sunset4@ietf.org" Subject: Re: [sunset4] WG Action: sunset4 (sunset4) 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, 08 May 2012 07:27:45 -0000 Sent from my iPad On May 8, 2012, at 12:19 AM, "Miya Kohno" wrote: > Hi, >=20 > I have two comments to the WG. >=20 > -------------- > I. Clarification on the description. >=20 > The description says "To facilitate the graceful sunsetting of the > IPv4 Internet". >=20 > Does this mean : > 1) IETF is to promote the transition > 2) Let the market decide the transition, and IETF is to minimize the > disruption during the transition >=20 > If 1), then we should aim more for migration. The solutions which have > been coming up so far are rather for IPv4 life extension or IPv4/v6 > co-existence, than for migration. >=20 > However, 2) might be more practical. The lessons we have learnt are > that we could not force nor promote the transition... And in that > case, IPv4 life extension (address sharing by NAPT44) and IPv4/v6 > co-existence (Encap/Tunnel/Translation) would make sense in terms of > minimizing the disruption. >=20 > -------------- > II. Scope of work >=20 > I'm afraid the works in this solution area so far tend to be scenario > development, rather than protocol/function development. The > consequence was the combinatorial explosion, wasn't it? For example, > if the element technologies are { NAPT44 | Encap/Tunnel | Translation > } and possible locations to put the functions are { host | CPE | GW@ > xSP }, then it comes 2^(3+3) =3D 64! (Of course this didn't exclude > impossible combination, but we have more variations (e.g. port > allocation schemes for NAPT44), so it could be worse...) >=20 > So I'm wondering if this WG could simplify the works and outcomes by > sorting out the element technologies and the frameworks. I believe this is the first milestone means. >=20 > Thanks, > Miya > _______________________________________________ > sunset4 mailing list > sunset4@ietf.org > https://www.ietf.org/mailman/listinfo/sunset4 From wesley.george@twcable.com Tue May 8 11:45:16 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 B61F521F8512 for ; Tue, 8 May 2012 11:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.68 X-Spam-Level: X-Spam-Status: No, score=-0.68 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6, 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 KvmpmfZ6ykh7 for ; Tue, 8 May 2012 11:45:16 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id CA76121F84FF for ; Tue, 8 May 2012 11:45:15 -0700 (PDT) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.75,552,1330923600"; d="scan'208";a="378289822" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 08 May 2012 14:44:30 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Tue, 8 May 2012 14:45:03 -0400 From: "George, Wes" To: Miya Kohno , "sunset4@ietf.org" Date: Tue, 8 May 2012 14:45:02 -0400 Thread-Topic: [sunset4] WG Action: sunset4 (sunset4) Thread-Index: Ac0s6udRkZfi4zakQ228vy9p2FhcPAAWh4ZQ 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: "marc.blanchet@viagenie.ca" Subject: Re: [sunset4] WG Action: sunset4 (sunset4) 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, 08 May 2012 18:45:17 -0000 I want to caveat my comments below by saying that the WG Chairs are still d= iscussing the finer points of this charter with the ADs for some clarificat= ion, so here is my own personal opinion. Not officially a WG chair comment,= but I have been privy to some discussions leading up to the formation of t= his WG that might help to clarify. Below inline... > -----Original Message----- > From: Miya Kohno [mailto:miya.kohno@gmail.com] > Sent: Tuesday, May 08, 2012 3:19 AM > To: sunset4@ietf.org > Cc: marc.blanchet@viagenie.ca; George, Wes > Subject: Re: [sunset4] WG Action: sunset4 (sunset4) > > I. Clarification on the description. > > The description says "To facilitate the graceful sunsetting of the > IPv4 Internet". > > Does this mean : > 1) IETF is to promote the transition > 2) Let the market decide the transition, and IETF is to minimize the dis= ruption > during the transition > [WEG] IPv4 sunset is specifically focused on two ideas: 1) many of the protocols and implementations don't have ways to gracefully = turn IPv4 completely off. They basically assume that IPv4 will always be pr= esent, even if they aren't actively using it for anything, and may consider= the lack of an IPv4 address a failure condition even when it isn't. For ex= ample, SOHO routers boot, request an IPv4 address, and respond to any DHCP = requests for IPv4. There's not really a way to shut that function off today= , especially remotely. We are charged with identifying those things and eit= her writing the protocol changes or generating the gap analysis so that the= appropriate WG can do so. Example - a DHCPv4 option code that says "IPv4 i= sn't supported" or a method to signal the NAT (and/or the hosts behind it) = that IPv4 can be used for local communication only (because there's no upst= ream IPv4 support), without resorting to simply sending TCP resets if they = try to connect to something via IPv4 etc. The idea of transitioning to IPv6= , whether it's feature parity issues (things missing in IPv6), or the rate = of deployment is really secondary to the work this group would be doing. 2) the concept from draft-george-ipv6-support that as a protocol suite, IPv= 4 is functionally complete, including a set of IPv4 extension/IPv6 transiti= on technologies that cover the majority of common use cases/problem sets. T= his is not declaring IPv4 historic, but rather a precursor, a "cap and grow= " change. We're saying that we don't need to continue making changes and "i= mprovements" to the protocol, and instead we need to be focusing on IPv6 or= IP-version-agnostic work. I do not think that this group could affect the rate of IPv4 -> IPv6 transi= tion much no matter what it did. There are lots and lots and lots of docume= nts talking the IPv4 to IPv6 transition to death, and if there is any stone= unturned, that's more of a subject for 6man or v6ops. This group starts wi= th the assumption that IPv6 critical mass is a foregone conclusion (rather = than something we need to push) and that we need to focus on making it poss= ible for people to "turn off the lights as they leave the IPv4 room." When = that actually happens is not relevant, because whenever that is, we need a = way to make it easier. The very act of declaring IPv4 "done" and working on= graceful exit/shutdown knobs in the protocol speaks much more loudly than = additional transition documents, IMO. > > -------------- > II. Scope of work > > I'm afraid the works in this solution area so far tend to be scenario > development, rather than protocol/function development. The > consequence was the combinatorial explosion, wasn't it? For example, if t= he > element technologies are { NAPT44 | Encap/Tunnel | Translation } and > possible locations to put the functions are { host | CPE | GW@ xSP }, the= n it > comes 2^(3+3) =3D 64! (Of course this didn't exclude impossible combinati= on, > but we have more variations (e.g. port allocation schemes for NAPT44), so= it > could be worse...) > [WEG] yes, in fact the idea is that we don't necessarily have to solve for = all possible combinations, but rather we need to solve for the ones that ha= ve the most real demand. So instead of 30 solutions that are only slight va= riations of one another but cover all of the corner cases exactly, we maybe= want to focus on nurturing 5 interoperable and widely-supported solutions = that cover 90% of those corner cases, and let the other 10% work with their= vendors on bespoke solutions where that makes sense. To your point above a= bout letting the market decide, IETF can't force operators to choose one so= lution over another. However, there is a better likelihood that the market = will coalesce if the IETF stops trying to solve for all values and focuses = on more flexible solutions that fit more problem/use cases, even if this re= quires us to acknowledge that we're purposely leaving some work undone. How= ever, I am not sure exactly how this group might be involved in that, other= than to use the tests listed in the charter as a method to determine which= things we (or the IETF itself) should be continuing to pursue. Hopefully this is helpful... 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.