From wesley.george@twcable.com Sun Jan 6 07:26:28 2013 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 1B9A221F8757 for ; Sun, 6 Jan 2013 07:26:28 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80iVph7lFn1N for ; Sun, 6 Jan 2013 07:26:27 -0800 (PST) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4322E21F8751 for ; Sun, 6 Jan 2013 07:26:27 -0800 (PST) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.84,419,1355115600"; d="scan'208";a="7456035" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 06 Jan 2013 10:24:58 -0500 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Sun, 6 Jan 2013 10:26:26 -0500 From: "George, Wes" To: "sunset4@ietf.org" Date: Sun, 6 Jan 2013 10:26:24 -0500 Thread-Topic: WG Review: Sunsetting IPv4 (sunset4) Thread-Index: Ac3qtFesfJwHNzgHQQ66Dah+gHQIywBba2Og Message-ID: <2671C6CDFBB59E47B64C10B3E0BD5923033AAB7959@PRVPEXVS15.corp.twcable.com> References: <20130104194655.18120.47954.idtracker@ietfa.amsl.com> In-Reply-To: <20130104194655.18120.47954.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sunset4] FW: WG Review: Sunsetting IPv4 (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: Sun, 06 Jan 2013 15:26:28 -0000 For those who aren't subscribed to ietf-announce. Here is the proposed vers= ion of our charter that has been reviewed by IESG. Thanks, Wes -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org= ] On Behalf Of The IESG Sent: Friday, January 04, 2013 2:47 PM To: IETF-Announce Subject: WG Review: Sunsetting IPv4 (sunset4) The Sunsetting IPv4 (sunset4) working group in the Internet Area of the IET= F is undergoing rechartering. The IESG has not made any determination yet. = The following draft charter was submitted, and is provided for informationa= l purposes only. Please send your comments to the IESG mailing list (iesg a= t ietf.org) by 2013-01-11. Sunsetting IPv4 (sunset4) ------------------------------------------------ Current Status: Active Working Group Chairs: Marc Blanchet Wesley George Technical advisors: Martin Stiemerling Stewart Bryant Fred Baker Assigned Area Director: Ralph Droms Mailing list Address: sunset4@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/sunset4 Archive: http://www.ietf.org/mail-archive/web/sunset4/ Charter of Working Group: Global IPv4 addresses, once considered plentiful, are an increasingly scarce resource for many who wish to connect to the Internet today. IPv6 provides an abundance of freely available addresses, and while deployment alongside IPv4 has begun in earnest, much work remains. In order to fully transition the Internet to IPv6, individual applications, hosts, and networks that have enabled IPv6 must also be able to operate fully in the absence of IPv4. The Working Group will point out specific areas of concern, provide recommendations, and standardize protocols that facilitate the graceful "sunsetting" of the IPv4 Internet in areas where IPv6 has been deployed. This includes the act of shutting down IPv4 itself, as well as the ability of IPv6-only portions of the Internet to continue to connect with portions of the Internet that remain IPv4-only. While this work obviously spans multiple IETF areas including Internet, Operations, Transport, Applications, and Routing, this working group provides a single venue for the consideration of IPv4 sunsetting. Work in this group shall never impede the deployment of IPv6, will not duplicate functions and capabilities already available in existing technologies, and should demonstrate widespread operational need. Cross- area coordination and support is essential. Disabling IPv4 in applications, hosts, and networks is new territory for much of the Internet today, and it is expected that problems will be uncovered including those related to basic IPv4 functionality, interoperability, as well as potential security concerns. The working group will report on common issues, provide recommendations, and, when necessary, protocol extensions in order to facilitate disabling IPv4 in networks where IPv6 has been deployed. As a rule, deployment scenarios considered by the working group shall include IPv6-only nodes and networks. Work on technologies that involve increased sharing of global IPv4 addresses should be limited to what is necessary for communicating with endpoints or over networks that are IPv6-only. The initial work items are: * NAT64 port allocation and address sharing methods involving scenarios where an IPv6-only node is present (and NAT44, as it overlaps NAT64 address sharing and port use). This may require a description of the use of an existing protocol, the development of extensions to an existing protocol, or the definition of an entirely new protocol. * Gap analysis of IPv4/IPv6 features to facilitate IPv4 sunsetting * Provisioning methods to signal a dual-stack host to disable or depreference the use of IPv4 Goals and Milestones: Mar 2013 - Submit gap analysis on IPv4 sunsetting to IESG for consideration as an Informational RFC Jun 2013 - Submit NAT64 port allocation and address sharing methods to IESG for consideration as an Informational RFC Sep 2013 - Submit provisioning methods to signal a dual-stack host to disable the use of IPv4 to IESG for consideration as Proposed Standard 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 Jan 22 09:13:12 2013 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 3CABA21F87E7 for ; Tue, 22 Jan 2013 09:13:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.462 X-Spam-Level: X-Spam-Status: No, score=-0.462 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvQNub3AEN4P for ; Tue, 22 Jan 2013 09:13:10 -0800 (PST) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 42E7821F895B for ; Tue, 22 Jan 2013 09:13:09 -0800 (PST) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.84,515,1355115600"; d="scan'208,217";a="15054520" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 22 Jan 2013 12:11:45 -0500 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.79]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Tue, 22 Jan 2013 12:12:39 -0500 From: "George, Wes" To: "sunset4@ietf.org" Date: Tue, 22 Jan 2013 12:12:38 -0500 Thread-Topic: Distributing Address Selection Policy using DHCPv6 Thread-Index: Ac34w6vR9rDzTT0ETl20MqkatMrFEw== Message-ID: <2671C6CDFBB59E47B64C10B3E0BD5923033C306947@PRVPEXVS15.corp.twcable.com> 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_2671C6CDFBB59E47B64C10B3E0BD5923033C306947PRVPEXVS15cor_" MIME-Version: 1.0 Cc: "draft-ietf-6man-addr-select-opt@tools.ietf.org" Subject: [sunset4] Distributing Address Selection Policy using DHCPv6 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, 22 Jan 2013 17:13:12 -0000 --_000_2671C6CDFBB59E47B64C10B3E0BD5923033C306947PRVPEXVS15cor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The draft draft-ietf-6man-addr-select-opt discusses a method to distribute= address selection policies via DHCPv6 that potentially override the defaul= t RFC6724 policies. http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-08 Since Sunset4 has been discussing the potential need to communicate not jus= t address selection within IPv6, but also potentially between IPv4 and IPv6= , it may be worth considering some additional functionality or use cases in= this draft or as a companion draft to cover the milestone in the sunset4 c= harter about signaling end hosts to disable or depreference the use of IPv4= . There is also the potential for other, more complex use cases to determin= e the proper preference for a given destination if and when an ISP is offer= ing some combination of: Native IPv4, IPv4 + CGN, Native IPv6, IPv6 + DNS64= /NAT64, etc. We don't necessarily have to make recommendations on what the = preferences should be, but it may be useful to illustrate these problems in= the draft and provide the framework to communicate more complex preference= s based on the individual implementers' situation. It would also be helpful= to be clear about the limitations of the complexity these options can real= istically and scalably represent - it's unlikely that this can be used for = very granular programming of an end host about which method to use for a la= rge subset of distinct prefixes, so an upper bound might be appropriate. 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_2671C6CDFBB59E47B64C10B3E0BD5923033C306947PRVPEXVS15cor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The draft  draft-ietf-6man-addr-select-opt disc= usses a method to distribute address selection policies via DHCPv6 that pot= entially override the default RFC6724 policies.

 

http://tools.ietf.org/html/draft-ietf-6man-addr-selec= t-opt-08

 

Since Sunset4 has been discussing the potential need= to communicate not just address selection within IPv6, but also potentiall= y between IPv4 and IPv6, it may be worth considering some additional functi= onality or use cases in this draft or as a companion draft to cover the milestone in the sunset4 charter abou= t signaling end hosts to disable or depreference the use of IPv4. There is = also the potential for other, more complex use cases to determine the prope= r preference for a given destination if and when an ISP is offering some combination of: Native IPv4, IPv4 += ; CGN, Native IPv6, IPv6 + DNS64/NAT64, etc. We don’t necessarily= have to make recommendations on what the preferences should be, but it may= be useful to illustrate these problems in the draft and provide the framework to communicate more complex preferences ba= sed on the individual implementers’ situation. It would also be helpf= ul to be clear about the limitations of the complexity these options can re= alistically and scalably represent – it’s unlikely that this can be used for very granular programming of an end hos= t about which method to use for a large subset of distinct prefixes, so an = upper bound might be appropriate.

 

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_2671C6CDFBB59E47B64C10B3E0BD5923033C306947PRVPEXVS15cor_--