From wwwrun@ietfa.amsl.com Mon Jun 6 09:54:56 2011 Return-Path: X-Original-To: fun@ietf.org Delivered-To: fun@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id 74F4411E8179; Mon, 6 Jun 2011 09:54:56 -0700 (PDT) From: IETF Secretariat To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110606165456.74F4411E8179@ietfa.amsl.com> Date: Mon, 6 Jun 2011 09:54:56 -0700 (PDT) Cc: fun@ietf.org Subject: [fun] New Non-WG Mailing List: fun -- FUture home Networking (FUN) X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 16:54:56 -0000 A new IETF non-working group email list has been created. List address: fun@ietf.org Archive: http://www.ietf.org/mail-archive/web/fun/ To subscribe: https://www.ietf.org/mailman/listinfo/fun Purpose: Mailing list for proposed working group on FUture home Networking (FUN) For additional information, please contact the list administrators. From bortzmeyer@nic.fr Tue Jun 7 00:16:06 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1B5611E80B7 for ; Tue, 7 Jun 2011 00:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.249 X-Spam-Level: X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fquzn9qSBOP9 for ; Tue, 7 Jun 2011 00:16:05 -0700 (PDT) Received: from mx2.nic.fr (mx2.nic.fr [IPv6:2001:660:3003:2::4:11]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8DD11E80C1 for ; Tue, 7 Jun 2011 00:16:04 -0700 (PDT) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 526721C00E4; Tue, 7 Jun 2011 09:16:02 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 4D0A81C00D5; Tue, 7 Jun 2011 09:16:02 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.6.69]) by relay2.nic.fr (Postfix) with ESMTP id 40CBC7B0037; Tue, 7 Jun 2011 09:16:02 +0200 (CEST) Date: Tue, 7 Jun 2011 09:16:02 +0200 From: Stephane Bortzmeyer To: Jari Arkko Message-ID: <20110607071602.GA4725@nic.fr> References: <20110606165456.74F4411E8179@ietfa.amsl.com> <20110606204755.GA32176@nic.fr> <6F2D64905D13DA87C2343EB7@PST.JCK.COM> <4DEDB0BC.7040906@piuha.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DEDB0BC.7040906@piuha.net> X-Operating-System: Debian GNU/Linux 6.0.1 X-Kernel: Linux 2.6.32-5-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.20 (2009-06-14) Cc: fun@ietf.org Subject: Re: [fun] New Non-WG Mailing List: fun -- FUture home Networking (FUN) X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 07:16:07 -0000 On Tue, Jun 07, 2011 at 08:01:48AM +0300, Jari Arkko wrote a message of 164 lines which said: > For name resolution and service discovery, extensions are needed to > mDNS and DNS-SD to enable them to work across subnets. There is currently one RFC about, how to call it, "local name resolution", it is RFC 4795. Why mentioning only the other proposal? From jari.arkko@piuha.net Tue Jun 7 08:25:02 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE62011E810C for ; Tue, 7 Jun 2011 08:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.06 X-Spam-Level: X-Spam-Status: No, score=-102.06 tagged_above=-999 required=5 tests=[AWL=-0.061, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJyT72smp24B for ; Tue, 7 Jun 2011 08:25:02 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 7DBED11E8152 for ; Tue, 7 Jun 2011 08:24:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id A22432D366 for ; Tue, 7 Jun 2011 18:24:38 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NzykPLAnSEuO for ; Tue, 7 Jun 2011 18:24:37 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id DE3CF2D35A for ; Tue, 7 Jun 2011 18:24:37 +0300 (EEST) Message-ID: <4DEE42B5.7030000@piuha.net> Date: Tue, 07 Jun 2011 18:24:37 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: fun@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [fun] proposed charter X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 15:25:03 -0000 FUture home Networks (FUN) ------------------------- Current Status: Proposed Last Edit: Friday, June 3rd, 2011 Chairs: TBD Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Routing Area Technical Advisor: TBD Security Area Technical Advisor: TBD Mailing Lists: General Discussion: fun@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/fun Archive: http://www.ietf.org/mail-archive/web/fun Description of Working Group: This working group focuses on the evolving networking technology in small networks such as those in homes. This evolution sets some requirements on IETF protocols. An obvious trend for home networking is the proliferation of networking technology in increasing number of different devices, from home entertainment systems to appliances and energy applications, just to name a few examples. This leads to a higher number of networked devices in each network. However, some more fundamental changes are occurring at the same time as well: o First, the link layer networking technology is become more heterogeneous, as networks are starting to employ, for instance, both traditional Ethernet technology and link layers designed for low-powered sensor networks. o Networks are also moving from a "one size fits all" model to dedicated segments for specific purposes. For instance, a common feature in high-end home routers in the ability to support both guest and private network segments. Similar needs for separation may occur in other cases, such as separating building control from the Internet access network. Typically, different subnets, routing and firewalls are used between the different segments. o Service providers are rolling out networks that support IPv6, and home gateway support for IPv6 is starting to appear. But for home networks, IPv6 is not just a new protocol, it also changes address allocation principles and allows end-to-end communication to the devices in the home. o End-to-end communication is both an opportunity and a problem, as it enables new applications but also exposes nodes in the internal networks to unwanted traffic from the Internet. Firewalls are in many cases needed to prevent exposure. However, this reduces the usefulness of end-to-end connectivity, as the firewall policy model is usually default deny, only allowing a small set of known protocols. In addition, consumer equipment typically reacts slowly if at all to changes in the typical Internet application, and it is likely that traffic for a popular application is not recognized by devices manufactured before that application was launched. Future home networks need to provide the tools to handle these situations in an easy manner. It is obvious that manual configuration is rarely possible. For IPv4, NAT and private address based solutions already provide limited solutions. The purpose of this working group is to develop an architecture and necessary additional tools for IPv6, to address the full scope of requirements: o prefix configuration for routers o managing routing (including turning it on by default) o name resolution o service discovery o perimeter security Specifically, the group should produce an architecture document that outlines how to construct home networks involving multiple routers and subnets. This document is expected to apply the IPv6 addressing architecture, prefix delegation, global and ULA addresses, source address selection rules and other existing components of the IPv6 architecture. In addition, the group will apply existing protocols to handle the five requirements above. For prefix configuration, DHCPv6 PD is an obvious candidate solution, possibly supplemented by some small enhancements, such as new options. For automatic routing, it is expected that existing routing protocols can be used as is, however, a new mechanism may be needed in order to turn a selected protocol on. For name resolution and service discovery, extensions are needed to mDNS and DNS-SD to enable them to work across subnets. For perimeter security, the group shall document the concept of "advanced security" as a further development of "simple security" from RFC 6092. The main goal of this work is to enable a default allow security policy. This may be accomplished, for instance, through driving security policy from an up-to-date database in the Internet or using simple security along with firewall control protocols such as PCP. It is expected that the working group defines a set of protocol specifications to accomplish the five requirements from above. However, it is NOT in the scope of the working group to define entirely new routing protocols or address allocation protocols. As noted additional options or other small extensions may be necessary to use the existing protocols in these new configuration tasks. The working group shall also not make any changes to IPv6 protocols or addressing architecture. Prefix configuration, routing, and security related work shall not cause any changes that are visible to hosts. There may be host visible changes in the work on naming and discovery protocols, however. In its design, the working group shall also consider security aspects and the impact on manageability. The working group will liaise with the relevant IETF working groups and other standards bodies. In particular, the group should work closely with the V6OPS working group, review any use or extension of DHCP with the DHC working group, and get feedback on DNS issues from the DNSEXT and DNSOP working groups. If it turns out that additional options are needed for a routing protocol, they will be developed in the appropriate Routing Area working group, with the FUN working group providing the architecture and requirements for such enhancements. Milestones: Oct 2011 First WG draft on the architecture Dec 2011 First WG draft on prefix configuration Dec 2011 First WG draft on routing Jan 2011 First WG draft on name resolution Feb 2011 First WG draft on service discovery Feb 2011 First WG draft on perimeter security Feb 2012 Submission of the architecture draft to the IESG as Informational RFC Feb 2012 Start of routing related work in the relevant routing area working group, if needed Mar 2012 Submission of the prefix configuration draft to the IESG as Standards Track RFC Apr 2012 Submission of the routing draft to the IESG as Informational RFC Jun 2012 Submission of the name resolution draft to the IESG as Standards Track RFC Jun 2012 Submission of the service discovery draft to the IESG as Standards Track RFC Aug 2012 Submission of the perimeter security draft to the IESG as Informational RFC From jari.arkko@piuha.net Tue Jun 7 08:26:04 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3B1D21F84CE for ; Tue, 7 Jun 2011 08:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.354 X-Spam-Level: X-Spam-Status: No, score=-102.354 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m61keIZoG3ne for ; Tue, 7 Jun 2011 08:26:03 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id E8A9621F84FB for ; Tue, 7 Jun 2011 08:26:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id BFA612CC4B; Tue, 7 Jun 2011 18:26:00 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UApNga-iv9Nh; Tue, 7 Jun 2011 18:26:00 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 55B5A2CC3B; Tue, 7 Jun 2011 18:26:00 +0300 (EEST) Message-ID: <4DEE4307.3070706@piuha.net> Date: Tue, 07 Jun 2011 18:25:59 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Stephane Bortzmeyer References: <20110606165456.74F4411E8179@ietfa.amsl.com> <20110606204755.GA32176@nic.fr> <6F2D64905D13DA87C2343EB7@PST.JCK.COM> <4DEDB0BC.7040906@piuha.net> <20110607071602.GA4725@nic.fr> In-Reply-To: <20110607071602.GA4725@nic.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: fun@ietf.org Subject: Re: [fun] New Non-WG Mailing List: fun -- FUture home Networking (FUN) X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 15:26:04 -0000 Stephane, >> For name resolution and service discovery, extensions are needed to >> mDNS and DNS-SD to enable them to work across subnets. >> > > There is currently one RFC about, how to call it, "local name > resolution", it is RFC 4795. Why mentioning only the other proposal? > I think this is a bug in the charter. It should really cover both. But I'm not the local name resolution expert. What do others think? Jari From bortzmeyer@nic.fr Mon Jun 6 13:48:02 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C1A921F84A1; Mon, 6 Jun 2011 13:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.249 X-Spam-Level: X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vK0hAKmF7Z8L; Mon, 6 Jun 2011 13:48:01 -0700 (PDT) Received: from mx2.nic.fr (mx2.nic.fr [IPv6:2001:660:3003:2::4:11]) by ietfa.amsl.com (Postfix) with ESMTP id B603621F849C; Mon, 6 Jun 2011 13:47:57 -0700 (PDT) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 7CAE21C0020; Mon, 6 Jun 2011 22:47:55 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx2.nic.fr (Postfix) with ESMTP id 776BF1C001B; Mon, 6 Jun 2011 22:47:55 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.6.69]) by relay1.nic.fr (Postfix) with ESMTP id 6BB195680CA; Mon, 6 Jun 2011 22:47:55 +0200 (CEST) Date: Mon, 6 Jun 2011 22:47:55 +0200 From: Stephane Bortzmeyer To: IETF Secretariat Message-ID: <20110606204755.GA32176@nic.fr> References: <20110606165456.74F4411E8179@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110606165456.74F4411E8179@ietfa.amsl.com> X-Operating-System: Debian GNU/Linux 6.0.1 X-Kernel: Linux 2.6.32-5-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.20 (2009-06-14) X-Mailman-Approved-At: Tue, 07 Jun 2011 08:28:25 -0700 Cc: ietf@ietf.org, fun@ietf.org Subject: Re: [fun] New Non-WG Mailing List: fun -- FUture home Networking (FUN) X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 20:48:02 -0000 On Mon, Jun 06, 2011 at 09:54:56AM -0700, IETF Secretariat wrote a message of 15 lines which said: > Purpose: Mailing list for proposed working group on FUture home Networking (FUN) And nothing more (same thing on the Web site). Could we ask for a little bit more context when a new IETF list is created? From jari.arkko@piuha.net Wed Jun 15 22:16:07 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D767B11E80BC for ; Wed, 15 Jun 2011 22:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.13 X-Spam-Level: X-Spam-Status: No, score=-102.13 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SDXSvOWyQOxo for ; Wed, 15 Jun 2011 22:16:07 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 8514811E80B4 for ; Wed, 15 Jun 2011 22:16:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id AF8672CC3B for ; Thu, 16 Jun 2011 08:16:05 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NyKCaeIF4Svk for ; Thu, 16 Jun 2011 08:16:03 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id B6FA72CC2F for ; Thu, 16 Jun 2011 08:16:03 +0300 (EEST) Message-ID: <4DF99193.3070305@piuha.net> Date: Thu, 16 Jun 2011 08:16:03 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: fun@ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: [fun] new version of the charter X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 05:16:08 -0000 Mark Townsley provided me with a suggested edit of the charter. I think it looks pretty good. Thoughts? Home Networks (homenet) ----------------------------------- Current Status: Proposed Last Edit: Friday, June 16th, 2011 Chairs: TBD Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Routing Area Technical Advisor: TBD Security Area Technical Advisor: TBD Mailing Lists: General Discussion: fun@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/fun Archive: http://www.ietf.org/mail-archive/web/fun Description of Working Group: This working group focuses on the evolving networking technology within and among relatively small “residential home” networks. For example, an obvious trend in home networking is the proliferation of networking technology in an increasingly broad range and number of devices. This evolution in scale and diversity sets some requirements on IETF protocols. Some of the relevant trends include: o Link layer networking technology is poised to become more heterogeneous, as networks begin to employ both traditional Ethernet technology and link layers designed for low-powered sensor networks. o Home networks are moving from a "one size fits all" model to incorporation of dedicated segments for specific purposes. For instance, a common feature in modern home routers in the ability to support both guest and private network segments. Similar needs for separation may occur in other cases, such as separating building control or corporate extensions from the Internet access network. Different segments may be associated with subnets that have different routing and security policies. o Service providers and are deploying IPv6, and support for IPv6 is increasingly available in home gateway devices. While IPv6 resembles IPv4 in many ways, it changes address allocation principles and allows direct IP addressability and routing to devices in the home from the Internet. This is a promising area in IPv6 that has proved challenging in IPv4 with the proliferation of NAT. o End-to-end communication is both an opportunity and a concern as it enables new applications but also exposes nodes in the internal networks to receipt of unwanted traffic from the Internet. Firewalls that restrict incoming connections may be used to prevent exposure, however, this reduces the efficacy of end-to-end connectivity that IPv6 has the potential to restore. Home networks need to provide the tools to handle these situations in a manner accessible to all users of home networks. Manual configuration is rarely, if at all, possible. The purpose of this working group is to focus on this evolution, in particular as it addresses the introduction of IPv6, by developing an architecture and necessary additional tools addressing this full scope of requirements: o prefix configuration for routers o managing routing o name resolution o service discovery o network security Specifically, the group will produce an architecture document that outlines how to construct home networks involving multiple routers and subnets. This document is expected to apply the IPv6 addressing architecture, prefix delegation, global and ULA addresses, source address selection rules and other existing components of the IPv6 architecture. In addition, the group will apply existing protocols to handle the five requirements above. For prefix configuration, DHCPv6 PD is an obvious candidate solution, possibly supplemented by some small enhancements, such as new options. For automatic routing, it is expected that existing routing protocols can be used as is, however, a new mechanism may be needed in order to turn a selected protocol on by default. For name resolution and service discovery, extensions are needed to mDNS and DNS-SD to enable them to work across subnets. For network security, the group shall document the concept of "advanced security" as a further development of "simple security" from RFC 6092. The main goal of this work is to enable a security policy that adapts to IPv6 threats as they emerge, taking into account not only traffic from the Internet at large, but within and leaving the home network itself. It is expected that the working group will define a set of protocol specifications to accomplish the five requirements from above. However, it is not in the scope of the working group to define entirely new routing protocols or address allocation protocols. As noted, additional options or other small extensions may be necessary to use the existing protocols in these new configuration tasks. The working group shall also not make any changes to IPv6 protocols or addressing architecture. Prefix configuration, routing, and security related work shall not cause any changes that are not backwards compatible to existing IPv6 hosts. There may be host visible changes in the work on naming and discovery protocols, however. In its design, the working group shall also consider security aspects and the impact on manageability. The main focus of the working group is home networks, but the group's results may also find applications in other small networks. The working group will liaise with the relevant IETF working groups and other standards bodies. In particular, the group should work closely with the V6OPS working group, review any use or extension of DHCP with the DHC working group, and get feedback on DNS issues from the DNSEXT and DNSOP working groups. If it turns out that additional options are needed for a routing protocol, they will be developed in the appropriate Routing Area working group, with the HOMENET working group providing the architecture and requirements for such enhancements. Milestones: Oct 2011 First WG draft on the architecture Dec 2011 First WG draft on prefix configuration Dec 2011 First WG draft on routing Jan 2011 First WG draft on name resolution Feb 2011 First WG draft on service discovery Feb 2011 First WG draft on perimeter security Feb 2012 Submission of the architecture draft to the IESG as Informational RFC Feb 2012 Start of routing related work in the relevant routing area working group, if needed Mar 2012 Submission of the prefix configuration draft to the IESG as Standards Track RFC Apr 2012 Submission of the routing draft to the IESG as Informational RFC Jun 2012 Submission of the name resolution draft to the IESG as Standards Track RFC Jun 2012 Submission of the service discovery draft to the IESG as Standards Track RFC Aug 2012 Submission of the perimeter security draft to the IESG as Informational RFC From ietfdbh@comcast.net Thu Jun 16 08:54:17 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A598B9E8044 for ; Thu, 16 Jun 2011 08:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.166 X-Spam-Level: X-Spam-Status: No, score=-102.166 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztQZP+7P97dI for ; Thu, 16 Jun 2011 08:54:16 -0700 (PDT) Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by ietfa.amsl.com (Postfix) with ESMTP id 92E869E8022 for ; Thu, 16 Jun 2011 08:54:16 -0700 (PDT) Received: from omta19.emeryville.ca.mail.comcast.net ([76.96.30.76]) by qmta11.emeryville.ca.mail.comcast.net with comcast id wf8A1g0061eYJf8ABfuE99; Thu, 16 Jun 2011 15:54:14 +0000 Received: from davidPC ([67.189.235.106]) by omta19.emeryville.ca.mail.comcast.net with comcast id wfuF1g00R2JQnJT01fuG3W; Thu, 16 Jun 2011 15:54:17 +0000 From: "David Harrington" To: "'Jari Arkko'" , References: <4DF99193.3070305@piuha.net> In-Reply-To: <4DF99193.3070305@piuha.net> Date: Thu, 16 Jun 2011 11:54:04 -0400 Message-ID: <1A856CBF79224F62A00EA161743A29F8@davidPC> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.1.7600.16776 Thread-index: Acwr5IFgr33jSaTWTm6JeBXeSV6NugAQwSfw Subject: Re: [fun] new version of the charter X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 15:54:17 -0000 Hi, a few comments: 1) I think this proposal is obviously AD-shopping with roughly the same proposal that was rejected last year, because the scope was too open-ended. I notice the FUN mailng list has no discussions on it. 2) "For automatic routing, it is expected that existing routing protocols can be used as is, however, a new mechanism may be needed in order to turn a selected protocol on by default." If you need a mechanism to turn it on, then it apparently is not on by default. Or it is on by default, but you need a mechanism for an administrator to turn it on/off as desired. 3) "It is expected that the working group will define a set of protocol specifications to accomplish the five requirements from above. ... Prefix configuration, routing, and security related work shall not cause any changes that are not backwards compatible to existing IPv6 hosts... The working group will liaise with the relevant IETF working groups and other standards bodies. " I think this is way too open-ended. Can this WG modify security protocol standards that have been developed in the security area? Can it modify protocols TCP options without bother to go through the TCP maintenece WG, which has been chartered to handle TCP maintenance issues? This charter certainly does not constrain such things. If the INT ADs want to allow a free-hand on modifying INT protocols, that's their business (to a degree), and obviously the charter has constraints on modification of INT protocols like DNS and DHCP. Giving these guys free rein to modify any protocol they choose, apparently from any area, seems over-reaching to me. I would be much more accepting of a charter that said they could identify proposed requirements and proposed changes to meet those requirements, but any such changes to existing protocols would need to be done by WGs in the appropriate area, or require a re-charter as deliverables for this WG to develop. I raise this point partly because, for example, it is important to keep TCP stable; but the TCPM WG gets (fairly) frequent requests to modify or add TCP options. If any TCP option proposals might be handled, I would want to know they go through the TCPM WG. If storage were to be addressed, I would want the storage experts from NFS/STORM involved. If a security protocol is going to be modified, I would want to know that the security experts have a hand in the design to ensure that the assumptions built into our current security standards . I do not find the following sufficiently constraining "The working group will liaise with the relevant IETF working groups and other standards bodies." I think, at a minimum, the area responsible for a protocol should be required to approve changes to their area's protocols. And the recharter process is designed to make sure that changes in WG direction are transparent, and that the IETF as a whole has rough consensus on the proposed WG directions. The charter as written seems to relieve the WG of the responsibility for such transparency and IETF consensus. 4) Even the text that does constrain their work on routing apparently gives them absolute control over the architecure and requirements: "If it turns out that additional options are needed for a routing protocol, they will be developed in the appropriate Routing Area working group, with the HOMENET working group providing the architecture and requirements for such enhancements." I would be happier with "with the HOMENET working group providing a proposed architecture and proposed requirements for such enhancements." 5) The HOMENET WG is mentioned in the charter. Is this proposed WG going to be called HOMENET? or FUN? 6) The milestones aren't very specific. "Oct 2011 First WG draft on the architecture" So is this WG going to define just one architecture that all home networks are expected to use? Do the home architectures typically found in US home networks match the architectures used in European home networks and Chinese home networks and South Amrican home networks? My impression is the relationship between ISPs and home users differ markedly between US users and Chinese home users. Are we favoring a particular architectural approach (and particular vendors) by defining one architecture? Would it be more realistic to call this "an" architecture? Is this really an appicability statement about the home network designs to which the other WG documents will apply? and is that architecture vendor-neutral? "Dec 2011 First WG draft on routing" and "Apr 2012 Submission of the routing draft to the IESG as Informational RFC" What is going to be included in this draft? proposed routing enhancements? proposed requirements? 7) If a similar open-ended charter were submitted to us by a proponent of clouds, such as Bhumip, or a proponent from Huawei or China Mobile, would we really approve such an open charter? 8) To look beyond just the charter of a specific WG, there has been a recent trend away from the Internet-stack approach, reflected in the IETF organization of INT/TSV/APP, toward a deployment/use-case and multi-layer approach to development, reflected in recent barBOFs and BOFs such as Clouds, data center, and home networking. Is this a direction the IETF should be going? Should we change our organizational structure (and possibly the architecture of the Internet) to reflect this change in thinking? Since the IESG members are the managers of the IETF standards process, should we be developing process regarding cross-area work such as clouds, data center, and home networking? David Harrington Director, IETF Transport Area ietfdbh@comcast.net (preferred for ietf) dbharrington@huaweisymantec.com +1 603 828 1401 (cell) > -----Original Message----- > From: fun-bounces@ietf.org [mailto:fun-bounces@ietf.org] On > Behalf Of Jari Arkko > Sent: Thursday, June 16, 2011 1:16 AM > To: fun@ietf.org > Subject: [fun] new version of the charter > > > Mark Townsley provided me with a suggested edit of the > charter. I think > it looks pretty good. Thoughts? > > Home Networks (homenet) > ----------------------------------- > > Current Status: Proposed > Last Edit: Friday, June 16th, 2011 > > Chairs: > TBD > > Internet Area Directors: > Ralph Droms > Jari Arkko > > Internet Area Advisor: > Jari Arkko > > Routing Area Technical Advisor: > TBD > > Security Area Technical Advisor: > TBD > > Mailing Lists: > General Discussion: fun@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/fun > Archive: http://www.ietf.org/mail-archive/web/fun > > Description of Working Group: > > This working group focuses on the evolving networking technology > within and among relatively small "residential home" networks. For > example, an obvious trend in home networking is the proliferation of > networking technology in an increasingly broad range and number of > devices. This evolution in scale and diversity sets some requirements > on IETF protocols. Some of the relevant trends include: > > o Link layer networking technology is poised to become more > heterogeneous, as networks begin to employ both traditional Ethernet > technology and link layers designed for low-powered sensor networks. > > o Home networks are moving from a "one size fits all" model to > incorporation of dedicated segments for specific purposes. For > instance, a common feature in modern home routers in the ability to > support both guest and private network segments. Similar needs for > separation may occur in other cases, such as separating building > control or corporate extensions from the Internet access > network. Different segments may be associated with subnets that have > different routing and security policies. > > o Service providers and are deploying IPv6, and support for IPv6 is > increasingly available in home gateway devices. While IPv6 resembles > IPv4 in many ways, it changes address allocation principles and allows > direct IP addressability and routing to devices in the home from the > Internet. This is a promising area in IPv6 that has proved challenging > in IPv4 with the proliferation of NAT. > > o End-to-end communication is both an opportunity and a concern as it > enables new applications but also exposes nodes in the internal > networks to receipt of unwanted traffic from the Internet. Firewalls > that restrict incoming connections may be used to prevent exposure, > however, this reduces the efficacy of end-to-end connectivity that > IPv6 has the potential to restore. > > Home networks need to provide the tools to handle these situations in > a manner accessible to all users of home networks. Manual > configuration is rarely, if at all, possible. The purpose of this > working group is to focus on this evolution, in particular as it > addresses the introduction of IPv6, by developing an architecture and > necessary additional tools addressing this full scope of requirements: > > o prefix configuration for routers > > o managing routing > > o name resolution > > o service discovery > > o network security > > Specifically, the group will produce an architecture document that > outlines how to construct home networks involving multiple routers and > subnets. This document is expected to apply the IPv6 addressing > architecture, prefix delegation, global and ULA addresses, source > address selection rules and other existing components of the IPv6 > architecture. > > In addition, the group will apply existing protocols to handle the > five requirements above. For prefix configuration, DHCPv6 PD is an > obvious candidate solution, possibly supplemented by some small > enhancements, such as new options. For automatic routing, it is > expected that existing routing protocols can be used as is, however, a > new mechanism may be needed in order to turn a selected protocol on by > default. For name resolution and service discovery, extensions are > needed to mDNS and DNS-SD to enable them to work across subnets. > > For network security, the group shall document the concept of > "advanced security" as a further development of "simple security" from > RFC 6092. The main goal of this work is to enable a security policy > that adapts to IPv6 threats as they emerge, taking into account not > only traffic from the Internet at large, but within and leaving the > home network itself. > > It is expected that the working group will define a set of protocol > specifications to accomplish the five requirements from > above. However, it is not in the scope of the working group to define > entirely new routing protocols or address allocation protocols. As > noted, additional options or other small extensions may be necessary > to use the existing protocols in these new configuration tasks. The > working group shall also not make any changes to IPv6 protocols or > addressing architecture. Prefix configuration, routing, and security > related work shall not cause any changes that are not backwards > compatible to existing IPv6 hosts. There may be host visible changes > in the work on naming and discovery protocols, however. In its design, > the working group shall also consider security aspects and the impact > on manageability. The main focus of the working group is home > networks, > but the group's results may also find applications in other small > networks. > > The working group will liaise with the relevant IETF working groups > and other standards bodies. In particular, the group should work > closely with the V6OPS working group, review any use or extension of > DHCP with the DHC working group, and get feedback on DNS issues from > the DNSEXT and DNSOP working groups. If it turns out that additional > options are needed for a routing protocol, they will be developed in > the appropriate Routing Area working group, with the HOMENET working > group providing the architecture and requirements for such > enhancements. > > Milestones: > > Oct 2011 First WG draft on the architecture > Dec 2011 First WG draft on prefix configuration > Dec 2011 First WG draft on routing > Jan 2011 First WG draft on name resolution > Feb 2011 First WG draft on service discovery > Feb 2011 First WG draft on perimeter security > Feb 2012 Submission of the architecture draft to the IESG as > Informational RFC > Feb 2012 Start of routing related work in the relevant routing area > working group, if needed > Mar 2012 Submission of the prefix configuration draft to the IESG as > Standards Track RFC > Apr 2012 Submission of the routing draft to the IESG as > Informational RFC > Jun 2012 Submission of the name resolution draft to the IESG as > Standards Track RFC > Jun 2012 Submission of the service discovery draft to the IESG as > Standards Track RFC > Aug 2012 Submission of the perimeter security draft to the IESG as > Informational RFC > > _______________________________________________ > fun mailing list > fun@ietf.org > https://www.ietf.org/mailman/listinfo/fun > From paul.hoffman@vpnc.org Sat Jun 25 09:10:38 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6CB21F8457 for ; Sat, 25 Jun 2011 09:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2KvVUYjqkRG for ; Sat, 25 Jun 2011 09:10:37 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id E623821F8483 for ; Sat, 25 Jun 2011 09:10:33 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p5PGAB8u024969 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 25 Jun 2011 09:10:11 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 25 Jun 2011 09:10:17 -0700 Message-Id: <16CD5318-7161-47D6-AB7C-7C240097B0F3@vpnc.org> To: fun@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [fun] Any signs of life here? X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2011 16:10:38 -0000 It looks like the BoF is scheduled (under then name "homenet") for = Quebec. However, the charter discussion seems to have fizzled out. Just = wondering... --Paul Hoffman From ietfdbh@comcast.net Mon Jun 27 10:52:39 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDDA011E814D for ; Mon, 27 Jun 2011 10:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.765 X-Spam-Level: X-Spam-Status: No, score=-101.765 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6uMaBuPwea4 for ; Mon, 27 Jun 2011 10:52:38 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id DFBE911E814E for ; Mon, 27 Jun 2011 10:52:33 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta09.westchester.pa.mail.comcast.net with comcast id 159b1h0031ei1Bg595saeo; Mon, 27 Jun 2011 17:52:34 +0000 Received: from davidPC ([67.189.235.106]) by omta24.westchester.pa.mail.comcast.net with comcast id 15sR1h00h2JQnJT3k5sSwN; Mon, 27 Jun 2011 17:52:31 +0000 From: "David Harrington" To: "'Jari Arkko'" , "'IAB'" , "'IESG'" , , References: <4E031DCD.1010606@piuha.net> In-Reply-To: <4E031DCD.1010606@piuha.net> Date: Mon, 27 Jun 2011 13:52:21 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.1.7600.16807 Thread-Index: AcwxlWHxRNcuhSEbSQa20cBMncQjdwDUSJ7Q Subject: Re: [fun] Revised homenet charter for IESG consideration X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 17:52:39 -0000 Hi, I think work on home networking standards is very important, and strongly support the effort. A little guidance on how I think this charter can be improved. >From the 110623 version, "Specific protocol work described below is anticipated to be within the scope of the working group. However, the group is required to review its charter and milestones with the IESG and IETF community before submitting documents that make protocol changes." "anticipated to be within the scope" is very unclear as to what is or is not in scope. Is that "anticipated to be within the scope" AFTER a re-charter, and thus is NOT NOW is scope of this charter? or is that "anticipated to be within the scope", so WG members can interpret it as being in scope NOW? My concern, and the concern of others, was that the original charter was too open-ended and did not provide for IETF review of the architecture and the potential changes it might drive before the WG was chartered to make such changes. This left potentially important, and possibly bad, changes in protocols to be caught in IETF Last Call or IESG Evaluation, rather than in a review of the proposed protocol work during the chartering process. The charter text makes it obvious that the engineering changes are not yet clearly understood: "The architecture document should drive what protocols changes, if any, are necessary." "existing protocols are likely sufficient, and at worst may need some small enhancements, ..." "it is expected that existing routing protocols can be used as is, however, a new mechanism may be needed ..." "The main goal of this [security] work is to enable a security policy that adapts to IPv6 threats as they emerge,..." This sounds more like the description of an IRTF RG than an IETF WG. The ***engineering*** apparently is not yet clearly understood, and the "specific protocol work described below" is not at all specific. If the engineering is not yet understood, then I think research needs to be done, and a resulting architecture document needs to be clear about what specific engineering work is needed, and a subsequent re-charter should be clear about the ***engineering*** work to be done. David Harrington Director, IETF Transport Area ietfdbh@comcast.net (preferred for ietf) dbharrington@huaweisymantec.com +1 603 828 1401 (cell) > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On > Behalf Of Jari Arkko > Sent: Thursday, June 23, 2011 7:05 AM > To: IAB; IESG; ipdir@ietf.org > Subject: Revised homenet charter for IESG consideration > > Secretary (Bcced), > > Please start an internal review and place this charter for > consideration > for external review in today's IESG telechat. (We will not approve it > for external review today, it will take at least until next > week. But I > would like to discuss it anyway.) > > All, > > This charter has been revised per discussion from the BOF call last > week. The biggest change is that the group is required to produce an > architecture document and then come back to the IESG/community to ask > for revising/confirming the rest of its charter. My plan is to create > the working group before Quebec City. Should that fail, the > backup plan > is to run a BOF. But I personally believe this is something > we could and > should charter now. I understand the concerns people raised > in the BOF > call and I'm hoping that this version has made some > significant progress > in resolving those concerns. > > Jari > > ----- > > Home Networks (homenet) > ----------------------------------- > > Current Status: Proposed > Last Edit: Friday, June 23rd, 2011 > > Chairs: > TBD > > Internet Area Directors: > Ralph Droms > Jari Arkko > > Internet Area Advisor: > Jari Arkko > > Routing Area Technical Advisor: > TBD > > Security Area Technical Advisor: > TBD > > Mailing Lists: > General Discussion: fun@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/fun > Archive: http://www.ietf.org/mail-archive/web/fun > > Description of Working Group: > > This working group focuses on the evolving networking technology > within and among relatively small "residential home" networks. For > example, an obvious trend in home networking is the proliferation of > networking technology in an increasingly broad range and number of > devices. This evolution in scale and diversity sets some requirements > on IETF protocols. Some of the relevant trends include: > > o Multiple segments: While less complex L3-toplogies involving as few > subnets as possible are preferred in home networks for a variety of > reasons including simpler management and service discovery, > incorporation of dedicated segments remain necessary for some > cases. For instance, a common feature in modern home routers in the > ability to support both guest and private network segments. Also, link > layer networking technology is poised to become more heterogeneous, as > networks begin to employ both traditional Ethernet technology and link > layers designed for low-powered sensor networks. Finally, similar > needs for segmentation may occur in other cases, such as separating > building control or corporate extensions from the Internet access > network. Different segments may be associated with subnets that have > different routing and security policies. > > o Service providers are deploying IPv6, and support for IPv6 is > increasingly available in home gateway devices. While IPv6 resembles > IPv4 in many ways, it changes address allocation principles and allows > direct IP addressability and routing to devices in the home from the > Internet. This is a promising area in IPv6 that has proved challenging > in IPv4 with the proliferation of NAT. > > o End-to-end communication is both an opportunity and a concern as it > enables new applications but also exposes nodes in the internal > networks to receipt of unwanted traffic from the Internet. Firewalls > that restrict incoming connections may be used to prevent exposure, > however, this reduces the efficacy of end-to-end connectivity that > IPv6 has the potential to restore. > > Home networks need to provide the tools to handle these situations in > a manner accessible to all users of home networks. Manual > configuration is rarely, if at all, possible. The purpose of this > working group is to focus on this evolution, in particular as it > addresses the introduction of IPv6, by developing an architecture > addressing this full scope of requirements: > > o prefix configuration for routers > o managing routing > o name resolution > o service discovery > o network security > > The task of the group is to produce an architecture document > that outlines > how to construct home networks involving multiple routers and > subnets. This document is expected to apply the IPv6 addressing > architecture, prefix delegation, global and ULA addresses, source > address selection rules and other existing components of the IPv6 > architecture. The architecture document should drive what protocols > changes, if any, are necessary. Specific protocol work described below > is anticipated to be within the scope of the working group. However, > the group is required to review its charter and milestones with the > IESG and IETF community before submitting documents that make protocol > changes. > > The group will apply existing protocols to handle the five > requirements above. For prefix configuration, existing protocols are > likely sufficient, and at worst may need some small enhancements, such > as new options. For automatic routing, it is expected that existing > routing protocols can be used as is, however, a new mechanism may be > needed in order to turn a selected protocol on by default. For name > resolution and service discovery, extensions to existing > multicast-based name resolution protocols are needed to enable them to > work across subnets. > > For network security, the group shall document the concept of > "advanced security" as a further development of "simple security" from > RFC 6092. The main goal of this work is to enable a security policy > that adapts to IPv6 threats as they emerge, taking into account not > only traffic from the Internet at large, but within and leaving the > home network itself. > > It is expected that the working group will define a set of protocol > specifications to accomplish the five requirements from > above. However, it is not in the scope of the working group to define > entirely new routing protocols or address allocation protocols. As > noted, additional options or other small extensions may be necessary > to use the existing protocols in these new configuration tasks. The > working group shall also not make any changes to IPv6 protocols or > addressing architecture. Prefix configuration, routing, and security > related work shall not cause any changes that are not backwards > compatible to existing IPv6 hosts. There may be host visible changes > in the work on naming and discovery protocols, however. In its design, > the working group shall also consider security aspects and the impact > on manageability. The main focus of the working group is home > networks, but the group's results may also find applications in other > small networks. > > The working group will liaise with the relevant IETF working > groups. In particular, the group should work closely with the V6OPS > working group, review any use or extension of DHCP with the DHC > working group, and work with additional DNS requirements with the > DNSEXT and DNSOP working groups. If it turns out that additional > options are needed for a routing protocol, they will be developed in > the appropriate Routing Area working group, with the HOMENET working > group providing the architecture and requirements for such > enhancements. The working group will also liase with external > standards bodies where it is expected that there are normative > dependencies between the specifications of the two bodies. > It is expected that in the architecture definition stage liaising > with the Broadband Forum, DLNA, and UPnP Forum is necessary. > > Milestones: > > Jul 2011 Formation of the working group > Sep 2011 First WG draft on the architecture > Dec 2011 Submission of the architecture draft to the IESG as > Informational RFC > Dec 2011 Charter re-evaluation based on the architecture work > Dec 2011 First WG draft on prefix configuration > Dec 2011 First WG draft on routing > Jan 2011 First WG draft on name resolution > Feb 2011 First WG draft on service discovery > Feb 2011 First WG draft on perimeter security > Feb 2012 Start of routing related work in the relevant routing area > working group, if needed > Mar 2012 Submission of the prefix configuration draft to the IESG as > Standards Track RFC > Apr 2012 Submission of the routing draft to the IESG as > Informational RFC > Jun 2012 Submission of the name resolution draft to the IESG as > Standards Track RFC > Jun 2012 Submission of the service discovery draft to the IESG as > Standards Track RFC > Aug 2012 Submission of the perimeter security draft to the IESG as > Informational RFC > > From rdroms@cisco.com Mon Jun 27 14:07:23 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB90D21F861A; Mon, 27 Jun 2011 14:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] 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 AhhyMBinVrX6; Mon, 27 Jun 2011 14:07:22 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id A0BE821F8610; Mon, 27 Jun 2011 14:07:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rdroms@cisco.com; l=13756; q=dns/txt; s=iport; t=1309208842; x=1310418442; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=RZCbqzJ/cVvbq3KMb7AJICc+C6VS0w1uvU5APin8ziI=; b=HwNkP5e6GbamhibUZ1Avtr74vf15H62DY+UeEJ+ZP/baiPmcKFYsKz/f LX5stZhudtgkl20qs+5tyi8bRT6/SK1jfOfzWFq5itnSNBPFJNw+m4er9 52YTfC1U5JLRKmxdFnZtdss2KETDCS7FjL+0YUAYClawaRiG/Y0XYoGKc c=; X-IronPort-AV: E=Sophos;i="4.65,434,1304294400"; d="scan'208";a="470823054" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by sj-iport-1.cisco.com with ESMTP; 27 Jun 2011 21:07:21 +0000 Received: from bxb-rdroms-8718.cisco.com (bxb-rdroms-8718.cisco.com [10.98.10.89]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5RL7KDL002074; Mon, 27 Jun 2011 21:07:20 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: Date: Mon, 27 Jun 2011 17:07:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E031DCD.1010606@piuha.net> To: "David Harrington" X-Mailer: Apple Mail (2.1084) Cc: ipdir@ietf.org, 'IAB' , 'IESG' , fun@ietf.org Subject: Re: [fun] Revised homenet charter for IESG consideration X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 21:07:24 -0000 On Jun 27, 2011, at 1:52 PM 6/27/11, David Harrington wrote: > Hi, >=20 > I think work on home networking standards is very important, and > strongly support the effort. > A little guidance on how I think this charter can be improved. David - frankly, you have given advice that this effort should be moved = to the IRTF. I see very little advice on how to improve the charter = for the WG in the IETF. > =46rom the 110623 version,=20 > "Specific protocol work described below is anticipated to be within=20 > the scope of the working group. However, > the group is required to review its charter and milestones with the > IESG and IETF community before submitting documents that make protocol > changes." >=20 > "anticipated to be within the scope" is very unclear as to what is or > is not in scope. > Is that "anticipated to be within the scope" AFTER a re-charter, and > thus is NOT NOW is scope of this charter? > or is that "anticipated to be within the scope", so WG members can > interpret it as being in scope NOW? Can this issue be fixed with a simple rewording: Specific protocol work described below is anticipated to be identified by the architecture document as areas of work to be chartered as within the scope of the working group.=20 > My concern, and the concern of others, was that the original charter I'd like to hear directly from others about their concerns regarding the current charter. > was too open-ended and did not provide for IETF review of the > architecture and the potential changes it might drive before the WG > was chartered to make such changes. This left potentially important, > and possibly bad, changes in protocols to be caught in IETF Last Call > or IESG Evaluation, rather than in a review of the proposed protocol > work during the chartering process. Do you still have this same concern about the *current* charter? >=20 > The charter text makes it obvious that the engineering changes are not > yet clearly understood:=20 > "The architecture document should drive what protocols changes, if > any, are necessary." > "existing protocols are likely sufficient, and at worst may need some > small enhancements, ..." > "it is expected that existing routing protocols can be used as is, > however, a new mechanism may be needed ..." > "The main goal of this [security] work is to enable a security policy > that adapts to IPv6 threats as they emerge,..." >=20 > This sounds more like the description of an IRTF RG than an IETF WG. > The ***engineering*** apparently is not yet clearly understood, and > the "specific protocol work described below" is not at all specific. I strongly disagree with you here. This charter represents engineering = work exactly as intended by the IETF. The WG is chartered to define an = architecture, and then engineer a system to meet the requirements of = that architecture using existing protocols as building blocks. Making a = home network work is clearly not a research problem. We know what needs = to be done, with the major constraint that a simple network of a few = links and routers has to operate with active admin intervention. The = hard work in the architecture will be to bound the problem and get = consensus on how many is "a few". If anything, the charter should more = strongly express the strength of its convictions and state explicitly = that existing protocols will be used with as few extensions as possible. = Otherwise, I'm fine with the charter as written and am happy to approve = it. - Ralph >=20 > If the engineering is not yet understood, then I think research needs > to be done, and a resulting architecture document needs to be clear > about what specific engineering work is needed, and a subsequent > re-charter should be clear about the ***engineering*** work to be > done. >=20 > David Harrington > Director, IETF Transport Area > ietfdbh@comcast.net (preferred for ietf) > dbharrington@huaweisymantec.com > +1 603 828 1401 (cell) >=20 >=20 >=20 >> -----Original Message----- >> From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On=20 >> Behalf Of Jari Arkko >> Sent: Thursday, June 23, 2011 7:05 AM >> To: IAB; IESG; ipdir@ietf.org >> Subject: Revised homenet charter for IESG consideration >>=20 >> Secretary (Bcced), >>=20 >> Please start an internal review and place this charter for=20 >> consideration=20 >> for external review in today's IESG telechat. (We will not approve > it=20 >> for external review today, it will take at least until next=20 >> week. But I=20 >> would like to discuss it anyway.) >>=20 >> All, >>=20 >> This charter has been revised per discussion from the BOF call last=20= >> week. The biggest change is that the group is required to produce an >=20 >> architecture document and then come back to the IESG/community to > ask=20 >> for revising/confirming the rest of its charter. My plan is to > create=20 >> the working group before Quebec City. Should that fail, the=20 >> backup plan=20 >> is to run a BOF. But I personally believe this is something=20 >> we could and=20 >> should charter now. I understand the concerns people raised=20 >> in the BOF=20 >> call and I'm hoping that this version has made some=20 >> significant progress=20 >> in resolving those concerns. >>=20 >> Jari >>=20 >> ----- >>=20 >> Home Networks (homenet) >> ----------------------------------- >>=20 >> Current Status: Proposed >> Last Edit: Friday, June 23rd, 2011 >>=20 >> Chairs: >> TBD >>=20 >> Internet Area Directors: >> Ralph Droms >> Jari Arkko >>=20 >> Internet Area Advisor: >> Jari Arkko >>=20 >> Routing Area Technical Advisor: >> TBD >>=20 >> Security Area Technical Advisor: >> TBD >>=20 >> Mailing Lists: >> General Discussion: fun@ietf.org >> To Subscribe: https://www.ietf.org/mailman/listinfo/fun >> Archive: http://www.ietf.org/mail-archive/web/fun >>=20 >> Description of Working Group: >>=20 >> This working group focuses on the evolving networking technology >> within and among relatively small "residential home" networks. For >> example, an obvious trend in home networking is the proliferation of >> networking technology in an increasingly broad range and number of >> devices. This evolution in scale and diversity sets some > requirements >> on IETF protocols. Some of the relevant trends include: >>=20 >> o Multiple segments: While less complex L3-toplogies involving as > few >> subnets as possible are preferred in home networks for a variety of >> reasons including simpler management and service discovery, >> incorporation of dedicated segments remain necessary for some >> cases. For instance, a common feature in modern home routers in the >> ability to support both guest and private network segments. Also, > link >> layer networking technology is poised to become more heterogeneous, > as >> networks begin to employ both traditional Ethernet technology and > link >> layers designed for low-powered sensor networks. Finally, similar >> needs for segmentation may occur in other cases, such as separating >> building control or corporate extensions from the Internet access >> network. Different segments may be associated with subnets that have >> different routing and security policies. >>=20 >> o Service providers are deploying IPv6, and support for IPv6 is >> increasingly available in home gateway devices. While IPv6 resembles >> IPv4 in many ways, it changes address allocation principles and > allows >> direct IP addressability and routing to devices in the home from the >> Internet. This is a promising area in IPv6 that has proved > challenging >> in IPv4 with the proliferation of NAT. >>=20 >> o End-to-end communication is both an opportunity and a concern as > it >> enables new applications but also exposes nodes in the internal >> networks to receipt of unwanted traffic from the Internet. Firewalls >> that restrict incoming connections may be used to prevent exposure, >> however, this reduces the efficacy of end-to-end connectivity that >> IPv6 has the potential to restore. >>=20 >> Home networks need to provide the tools to handle these situations > in >> a manner accessible to all users of home networks. Manual >> configuration is rarely, if at all, possible. The purpose of this >> working group is to focus on this evolution, in particular as it >> addresses the introduction of IPv6, by developing an architecture >> addressing this full scope of requirements: >>=20 >> o prefix configuration for routers >> o managing routing >> o name resolution >> o service discovery >> o network security >>=20 >> The task of the group is to produce an architecture document=20 >> that outlines >> how to construct home networks involving multiple routers and >> subnets. This document is expected to apply the IPv6 addressing >> architecture, prefix delegation, global and ULA addresses, source >> address selection rules and other existing components of the IPv6 >> architecture. The architecture document should drive what protocols >> changes, if any, are necessary. Specific protocol work described > below >> is anticipated to be within the scope of the working group. However, >> the group is required to review its charter and milestones with the >> IESG and IETF community before submitting documents that make > protocol >> changes. >>=20 >> The group will apply existing protocols to handle the five >> requirements above. For prefix configuration, existing protocols are >> likely sufficient, and at worst may need some small enhancements, > such >> as new options. For automatic routing, it is expected that existing >> routing protocols can be used as is, however, a new mechanism may be >> needed in order to turn a selected protocol on by default. For name >> resolution and service discovery, extensions to existing >> multicast-based name resolution protocols are needed to enable them > to >> work across subnets. >>=20 >> For network security, the group shall document the concept of >> "advanced security" as a further development of "simple security" > from >> RFC 6092. The main goal of this work is to enable a security policy >> that adapts to IPv6 threats as they emerge, taking into account not >> only traffic from the Internet at large, but within and leaving the >> home network itself. >>=20 >> It is expected that the working group will define a set of protocol >> specifications to accomplish the five requirements from >> above. However, it is not in the scope of the working group to > define >> entirely new routing protocols or address allocation protocols. As >> noted, additional options or other small extensions may be necessary >> to use the existing protocols in these new configuration tasks. The >> working group shall also not make any changes to IPv6 protocols or >> addressing architecture. Prefix configuration, routing, and security >> related work shall not cause any changes that are not backwards >> compatible to existing IPv6 hosts. There may be host visible changes >> in the work on naming and discovery protocols, however. In its > design, >> the working group shall also consider security aspects and the > impact >> on manageability. The main focus of the working group is home >> networks, but the group's results may also find applications in > other >> small networks. >>=20 >> The working group will liaise with the relevant IETF working >> groups. In particular, the group should work closely with the V6OPS >> working group, review any use or extension of DHCP with the DHC >> working group, and work with additional DNS requirements with the >> DNSEXT and DNSOP working groups. If it turns out that additional >> options are needed for a routing protocol, they will be developed in >> the appropriate Routing Area working group, with the HOMENET working >> group providing the architecture and requirements for such >> enhancements. The working group will also liase with external >> standards bodies where it is expected that there are normative >> dependencies between the specifications of the two bodies. >> It is expected that in the architecture definition stage liaising >> with the Broadband Forum, DLNA, and UPnP Forum is necessary. >>=20 >> Milestones: >>=20 >> Jul 2011 Formation of the working group >> Sep 2011 First WG draft on the architecture >> Dec 2011 Submission of the architecture draft to the IESG as=20 >> Informational RFC >> Dec 2011 Charter re-evaluation based on the architecture work >> Dec 2011 First WG draft on prefix configuration >> Dec 2011 First WG draft on routing >> Jan 2011 First WG draft on name resolution >> Feb 2011 First WG draft on service discovery >> Feb 2011 First WG draft on perimeter security >> Feb 2012 Start of routing related work in the relevant routing area=20= >> working group, if needed >> Mar 2012 Submission of the prefix configuration draft to the IESG as >=20 >> Standards Track RFC >> Apr 2012 Submission of the routing draft to the IESG as=20 >> Informational RFC >> Jun 2012 Submission of the name resolution draft to the IESG as=20 >> Standards Track RFC >> Jun 2012 Submission of the service discovery draft to the IESG as=20 >> Standards Track RFC >> Aug 2012 Submission of the perimeter security draft to the IESG as=20 >> Informational RFC >>=20 >>=20 >=20 > _______________________________________________ > fun mailing list > fun@ietf.org > https://www.ietf.org/mailman/listinfo/fun From jari.arkko@piuha.net Mon Jun 27 15:52:53 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 042271F0C51; Mon, 27 Jun 2011 15:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.996 X-Spam-Level: X-Spam-Status: No, score=-101.996 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FdxKa44OeJkL; Mon, 27 Jun 2011 15:52:52 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id DE4751F0C49; Mon, 27 Jun 2011 15:52:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 46A842CC39; Tue, 28 Jun 2011 01:52:50 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYooj4Bq6RNs; Tue, 28 Jun 2011 01:52:49 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 0634C2CC2F; Tue, 28 Jun 2011 01:52:48 +0300 (EEST) Message-ID: <4E0909C0.1090108@piuha.net> Date: Tue, 28 Jun 2011 00:52:48 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: David Harrington References: <4E031DCD.1010606@piuha.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipdir@ietf.org, 'IAB' , 'IESG' , fun@ietf.org Subject: Re: [fun] Revised homenet charter for IESG consideration X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 22:52:53 -0000 David, > I think work on home networking standards is very important, and > strongly support the effort. > A little guidance on how I think this charter can be improved. > Great! > >From the 110623 version, > "Specific protocol work described below is anticipated to be within > the scope of the working group. However, > the group is required to review its charter and milestones with the > IESG and IETF community before submitting documents that make protocol > changes." > > "anticipated to be within the scope" is very unclear as to what is or > is not in scope. > Is that "anticipated to be within the scope" AFTER a re-charter, and > thus is NOT NOW is scope of this charter? > After the recharter. I can clarify this. And it already says what specifically is not in scope (submitting documents that make protocol changes). How about this: OLD: Specific protocol work described below is anticipated to be within the scope of the working group. However, the group is required to review its charter and milestones with the IESG and IETF community before submitting documents that make protocol changes. NEW: Specific protocol work described below is expected to be within the scope of the working group one the architecture work is complete. However, the group is required to review its charter and milestones with the IESG and IETF community before submitting documents that make protocol changes. It is expected that the group has to discuss some of the below solutions, however, in order to complete the architecture work. Would this be clearer? > or is that "anticipated to be within the scope", so WG members can > interpret it as being in scope NOW? > > My concern, and the concern of others, was that the original charter > was too open-ended and did not provide for IETF review of the > architecture and the potential changes it might drive before the WG > was chartered to make such changes. This left potentially important, > and possibly bad, changes in protocols to be caught in IETF Last Call > or IESG Evaluation, rather than in a review of the proposed protocol > work during the chartering process. > Right. I was one of those ADs who balloted against the charter back then. But lets focus on the current charter. I don't think this issue exists in the current charter as written. > The charter text makes it obvious that the engineering changes are not > yet clearly understood: > That's right. There's some work to be done. And given your comments from a couple of IESG meetings ago, we've changed the charter so that the architecture and plan for changes needs to come first. Once it is clear, the group can proceed for real with the changes. > "The architecture document should drive what protocols changes, if > any, are necessary." > "existing protocols are likely sufficient, and at worst may need some > small enhancements, ..." > "it is expected that existing routing protocols can be used as is, > however, a new mechanism may be needed ..." > "The main goal of this [security] work is to enable a security policy > that adapts to IPv6 threats as they emerge,..." > > This sounds more like the description of an IRTF RG than an IETF WG. > The ***engineering*** apparently is not yet clearly understood, and > the "specific protocol work described below" is not at all specific. > I think we need to distinguish engineering efforts with a priori known end result (build this house) from those with more initial effort on requirements (build the optimal house for this family) and from research (develop new materials technology for houses). HOMENET is of the second type. In general, the IETF does not work only on the first type of efforts. We do constrain (and sometimes over- or under-constrain) efforts based on specific concerns, of course. The method that we're using in this case is to have the scope of solutions work decided by the IESG/IETF only after the architecture is clear. Continuing with the house construction analogy, this is like asking for the architects to make a plan for the house before committing to materials and construction contracts. However, just like with architecture, materials choices and technology has to be discussed as part of the architectural design, as they drive what can be built. > a resulting architecture document needs to be clear > about what specific engineering work is needed, and a subsequent > re-charter should be clear about the ***engineering*** work to be > done. I think that is the intent. Is there something missing from the current charter text with regards to this? It says: The task of the group is to produce an architecture document that outlines how to construct home networks involving multiple routers and subnets. This document is expected to apply ... and other existing components of the IPv6 architecture. The architecture document should drive what protocols changes, if any, are necessary. Jari From rdroms@cisco.com Tue Jun 28 03:16:47 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3509721F85AE; Tue, 28 Jun 2011 03:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id luzlUgNSjN0l; Tue, 28 Jun 2011 03:16:47 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 7166821F85BE; Tue, 28 Jun 2011 03:16:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rdroms@cisco.com; l=504; q=dns/txt; s=iport; t=1309256206; x=1310465806; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=DJDSsBDd4YJiwj1BF4SIdxDUmX6liLG6yzW/rRQFOIE=; b=kLNgYvdTYqDNkS+F4CeVYl5X6gzFZUQvLlNAJLob3EpAjvgv20MimOHG zMyLR2fIaMk7sAyxCtUPPYlz1FLp/7AxwxJx5XWQdtNUyCvyNY1LG8hfj cX8mYmT71lSXDqXmnfBCqoTw6qs3l7S0llrjEQQqq/m6wBHXfZ+fcLJfj U=; X-IronPort-AV: E=Sophos;i="4.65,436,1304294400"; d="scan'208";a="39620845" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 28 Jun 2011 10:16:42 +0000 Received: from bxb-rdroms-8718.cisco.com (bxb-rdroms-8718.cisco.com [10.98.10.89]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5SAGfwv008080; Tue, 28 Jun 2011 10:16:42 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: Date: Tue, 28 Jun 2011 06:16:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E031DCD.1010606@piuha.net> To: "David Harrington" X-Mailer: Apple Mail (2.1084) Cc: ipdir@ietf.org, 'IAB' , 'IESG' , fun@ietf.org Subject: Re: [fun] Revised homenet charter for IESG consideration X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 10:16:47 -0000 On Jun 27, 2011, at 1:52 PM 6/27/11, David Harrington wrote: > [...] > This sounds more like the description of an IRTF RG than an IETF WG. > The ***engineering*** apparently is not yet clearly understood, and > the "specific protocol work described below" is not at all specific. [...] with the major constraint that a simple network of a few links and = routers has to operate with active admin intervention. s/with active admin intervention/without active admin intervention/ - Ralph From rturner@amalfisystems.com Tue Jun 28 07:06:52 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8332A21F8546; Tue, 28 Jun 2011 07:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 YFP1qZlnGJD4; Tue, 28 Jun 2011 07:06:51 -0700 (PDT) Received: from omr13.networksolutionsemail.com (omr13.networksolutionsemail.com [205.178.146.63]) by ietfa.amsl.com (Postfix) with ESMTP id 3110321F8506; Tue, 28 Jun 2011 07:06:48 -0700 (PDT) Received: from cm-omr9 (mail.networksolutionsemail.com [205.178.146.50]) by omr13.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p5SE6j4w022816; Tue, 28 Jun 2011 10:06:47 -0400 X-Authenticated-IP: 174.254.67.139 Received: from [174.254.67.139] ([174.254.67.139:48505] helo=[10.224.112.70]) by cm-omr9 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTP id 34/D2-10086-0FFD90E4; Tue, 28 Jun 2011 10:06:45 -0400 References: <4E031DCD.1010606@piuha.net> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8E401) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <3A1DC425-BF54-4CD1-A7D4-5AF668680DB5@amalfisystems.com> X-Mailer: iPhone Mail (8E401) From: Randy Turner Date: Tue, 28 Jun 2011 07:06:34 -0700 To: Ralph Droms Cc: "ipdir@ietf.org" , IAB , IESG , "fun@ietf.org" Subject: Re: [fun] Revised homenet charter for IESG consideration X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 14:06:52 -0000 "without active administration" should probably be the goal regardless of to= pology.., Randy On Jun 28, 2011, at 3:16 AM, Ralph Droms wrote: >=20 > On Jun 27, 2011, at 1:52 PM 6/27/11, David Harrington wrote: >> [...] >> This sounds more like the description of an IRTF RG than an IETF WG. >> The ***engineering*** apparently is not yet clearly understood, and >> the "specific protocol work described below" is not at all specific. >=20 > [...] with the major constraint that a simple network of a few links and r= outers has to operate with active admin intervention. >=20 > s/with active admin intervention/without active admin intervention/ >=20 > - Ralph >=20 >=20 >=20 > _______________________________________________ > fun mailing list > fun@ietf.org > https://www.ietf.org/mailman/listinfo/fun >=20 From spencer@wonderhamster.org Tue Jun 28 07:24:05 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC06521F86D6; Tue, 28 Jun 2011 07:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.739 X-Spam-Level: X-Spam-Status: No, score=-100.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, STOX_REPLY_TYPE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7K7MsFXYuLlh; Tue, 28 Jun 2011 07:24:04 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id A1AC921F86D5; Tue, 28 Jun 2011 07:24:04 -0700 (PDT) Received: from S73602b ([50.58.7.243]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0M3AGF-1RTX4M3WxL-00sj1C; Tue, 28 Jun 2011 10:24:02 -0400 Message-ID: <3078175EB93B4A4C95E7ACC5F7701D77@china.huawei.com> From: "Spencer Dawkins" To: , "'IAB'" , "'IESG'" , References: <4E031DCD.1010606@piuha.net> Date: Tue, 28 Jun 2011 09:23:53 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 X-Provags-ID: V02:K0:ClF1opSfgiB0nltaqDBDexJS2PX/ZPzxz0bx31UJjzs NkyYW/hY4i6DlrYRksb89mF8Idztq9A18PF+DT8rO7d3N2M1h4 n7cM+3L2q3iHpHJOFAWtLGeDPk0srFxS75kljsOFrauade/o8t DYhlv+A+aClt8mX/q+/vVSq6MbFTty3eFr7w9fODDiYsG/zbaX ZmdU/Ts2frQOH5OMDkX3R1PkdGRJNS6IMs3pdninRg= Subject: Re: [fun] [IAB] Revised homenet charter for IESG consideration X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 14:24:05 -0000 Dear INT ADs, I don't want to interrupt the food fight just to ask someone to pass the salt, but ... :D The current (last I saw) proposed charter for HOMENET didn't seem quite clear enough that having "as few subnets as possible" doesn't make the complexity of having multiple subnets go away. I was hoping that this could be stated a little more bluntly. Could I suggest something like OLD: o Multiple segments: While less complex L3-toplogies involving as few subnets as possible are preferred in home networks for a variety of reasons including simpler management and service discovery, incorporation of dedicated segments remain necessary for some cases. For instance, ... (excellent reasons deleted because I wasn't questioning them) NEW: o Multiple segments: While less complex L3-toplogies involving as few subnets as possible are preferred in home networks for a variety of reasons including simpler management and service discovery, the introduction of more than one subnet into a home network is enough to add complexity that needs to be addressed, and multiple dedicated segments are necessary for some cases. For instance, ... (excellent reasons remain unchanged) I hope this is a helpful comment, because I don't want to derail the general conversation by saying something NOT helpful. Spencer From rdroms@cisco.com Tue Jun 28 07:30:19 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C60321F84D7; Tue, 28 Jun 2011 07:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e2q0sMDvSK3i; Tue, 28 Jun 2011 07:30:16 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 7DCCE21F84D3; Tue, 28 Jun 2011 07:30:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rdroms@cisco.com; l=1207; q=dns/txt; s=iport; t=1309271416; x=1310481016; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Q03j8Gh8jULzKNIpJfc880xTJ8OIXHhNtF0y4gJlvVs=; b=Vdcu7WflHAkUcJAgLv57AmTodC8XZox9nZkEXofUPEVZAohPfr0y8XR2 MQMtDYFcnmRWGQFVI0wyqkWxgF75cn6dCAmYOxYLbsK533FYDzy6vimsc aV54P4vTVlMjPlvtnO+cIea3sIS8LT0ev2N2tlOFvFzNQ2OHsGctGelsA 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAGXkCU6rRDoG/2dsb2JhbABSp0F3iHejBZ49hjAEkhCQPQ X-IronPort-AV: E=Sophos;i="4.65,437,1304294400"; d="scan'208";a="387733912" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 28 Jun 2011 14:30:16 +0000 Received: from bxb-rdroms-8718.cisco.com (bxb-rdroms-8718.cisco.com [10.98.10.89]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5SEUC3q024433; Tue, 28 Jun 2011 14:30:14 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: <3A1DC425-BF54-4CD1-A7D4-5AF668680DB5@amalfisystems.com> Date: Tue, 28 Jun 2011 10:30:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <91E6E187-35C3-43CF-BF3D-FC36FAA375DE@cisco.com> References: <4E031DCD.1010606@piuha.net> <3A1DC425-BF54-4CD1-A7D4-5AF668680DB5@amalfisystems.com> To: Randy Turner X-Mailer: Apple Mail (2.1084) Cc: ipdir@ietf.org, IAB IAB , IESG IESG , fun@ietf.org Subject: Re: [fun] Revised homenet charter for IESG consideration X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 14:30:19 -0000 On Jun 28, 2011, at 10:06 AM 6/28/11, Randy Turner wrote: > "without active administration" should probably be the goal regardless = of topology.., Obscure wording on my part. What I was trying to express was, in fact, = homenet should do its work within two independent constraints: * simple network of a few links and routers * operates without active admin intervention - Ralph >=20 > Randy >=20 > On Jun 28, 2011, at 3:16 AM, Ralph Droms wrote: >=20 >>=20 >> On Jun 27, 2011, at 1:52 PM 6/27/11, David Harrington wrote: >>> [...] >>> This sounds more like the description of an IRTF RG than an IETF WG. >>> The ***engineering*** apparently is not yet clearly understood, and >>> the "specific protocol work described below" is not at all specific. >>=20 >> [...] with the major constraint that a simple network of a few links = and routers has to operate with active admin intervention. >>=20 >> s/with active admin intervention/without active admin intervention/ >>=20 >> - Ralph >>=20 >>=20 >>=20 >> _______________________________________________ >> fun mailing list >> fun@ietf.org >> https://www.ietf.org/mailman/listinfo/fun >>=20 From townsley@cisco.com Tue Jun 28 07:34:09 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7D411E8108; Tue, 28 Jun 2011 07:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcU01oMwBSs5; Tue, 28 Jun 2011 07:34:09 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id AC01F11E80BE; Tue, 28 Jun 2011 07:34:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=townsley@cisco.com; l=1701; q=dns/txt; s=iport; t=1309271649; x=1310481249; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=d6OIVz5EgWXT5bVAJ6Mvl1/xtbXtCEfB+KuXj/UR6vs=; b=NwlAxc0AmCnG7CKf9czOu7vvE7hjS6iwb8Zaxqo02R2hYRS+Ud32oMdt c2FNt/1fwIskRjoLtIfskV/WsgQdFsrw5LaZXoh1WvUINWhUifp1yvKpK bk/VVZK9/RYNBEx9weC68oxVbnhXHZtCDM5jhVBzUdTm7gl3YQ0qEbVzR w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAJflCU6Q/khL/2dsb2JhbABSp0F3iHeic545hjAEkhCEbos1 X-IronPort-AV: E=Sophos;i="4.65,437,1304294400"; d="scan'208";a="39662729" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 28 Jun 2011 14:34:05 +0000 Received: from [64.103.29.80] ([64.103.29.80]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5SEY5kE006883; Tue, 28 Jun 2011 14:34:05 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Townsley X-Priority: 3 In-Reply-To: <3078175EB93B4A4C95E7ACC5F7701D77@china.huawei.com> Date: Tue, 28 Jun 2011 16:34:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2184F014-FEAD-4958-843F-8ED099D0A320@cisco.com> References: <4E031DCD.1010606@piuha.net> <3078175EB93B4A4C95E7ACC5F7701D77@china.huawei.com> To: "Spencer Dawkins" X-Mailer: Apple Mail (2.1084) Cc: ipdir@ietf.org, 'IAB' , 'IESG' , fun@ietf.org Subject: Re: [fun] [IAB] Revised homenet charter for IESG consideration X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 14:34:09 -0000 Thanks Spencer. For my part, I have no problem with your proposed text. - Mark On Jun 28, 2011, at 4:23 PM, Spencer Dawkins wrote: > Dear INT ADs, >=20 > I don't want to interrupt the food fight just to ask someone to pass = the salt, but ... :D >=20 > The current (last I saw) proposed charter for HOMENET didn't seem = quite clear enough that having "as few subnets as possible" doesn't make = the complexity of having multiple subnets go away. I was hoping that = this could be stated a little more bluntly. >=20 > Could I suggest something like >=20 > OLD: o Multiple segments: While less complex L3-toplogies involving as = few > subnets as possible are preferred in home networks for a variety of > reasons including simpler management and service discovery, > incorporation of dedicated segments remain necessary for some > cases. For instance, ... (excellent reasons deleted because I wasn't = questioning them) >=20 > NEW: o Multiple segments: While less complex L3-toplogies involving as = few subnets as possible are preferred in home networks for a variety of = reasons including simpler management and service discovery, the = introduction of more than one subnet into a home network is enough to = add complexity that needs to be addressed, and multiple dedicated = segments are necessary for some cases. For instance, ... (excellent = reasons remain unchanged) >=20 > I hope this is a helpful comment, because I don't want to derail the = general conversation by saying something NOT helpful. >=20 > Spencer=20 > _______________________________________________ > fun mailing list > fun@ietf.org > https://www.ietf.org/mailman/listinfo/fun From townsley@cisco.com Tue Jun 28 07:38:40 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7865911E810E; Tue, 28 Jun 2011 07:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aDrst+FtV3gg; Tue, 28 Jun 2011 07:38:39 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 752C411E80C3; Tue, 28 Jun 2011 07:38:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=townsley@cisco.com; l=1101; q=dns/txt; s=iport; t=1309271919; x=1310481519; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=RlqvQ/9+BoSQQ9OonSfBBO+lEnV/uFNCtD3wJYeb9ns=; b=FTSkw/MyrAcXnZgp7+bHLoJhsFqCg6BAPn00M6Mz5fBf2Dmv83KUDRmI oOtX5IFQmuVeNk3Cdl575DrfTL0V9GZls48DZLqRGvW100uoHoPW8O3t1 jC6ZIib6JqVaSXqKcGMwy93DnmvhkV2ogELlmGI8YDhMzi2gEfAyOpRrH 0=; X-IronPort-AV: E=Sophos;i="4.65,437,1304294400"; d="scan'208";a="39663296" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 28 Jun 2011 14:38:37 +0000 Received: from [64.103.29.80] ([64.103.29.80]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5SEcbSQ008041; Tue, 28 Jun 2011 14:38:37 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: <3A1DC425-BF54-4CD1-A7D4-5AF668680DB5@amalfisystems.com> Date: Tue, 28 Jun 2011 16:38:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E031DCD.1010606@piuha.net> <3A1DC425-BF54-4CD1-A7D4-5AF668680DB5@amalfisystems.com> To: Randy Turner X-Mailer: Apple Mail (2.1084) Cc: "fun@ietf.org" , "ipdir@ietf.org" , IAB , IESG Subject: Re: [fun] Revised homenet charter for IESG consideration X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 14:38:40 -0000 On Jun 28, 2011, at 4:06 PM, Randy Turner wrote: > "without active administration" should probably be the goal regardless = of topology.., +1 - Mark >=20 > Randy >=20 > On Jun 28, 2011, at 3:16 AM, Ralph Droms wrote: >=20 >>=20 >> On Jun 27, 2011, at 1:52 PM 6/27/11, David Harrington wrote: >>> [...] >>> This sounds more like the description of an IRTF RG than an IETF WG. >>> The ***engineering*** apparently is not yet clearly understood, and >>> the "specific protocol work described below" is not at all specific. >>=20 >> [...] with the major constraint that a simple network of a few links = and routers has to operate with active admin intervention. >>=20 >> s/with active admin intervention/without active admin intervention/ >>=20 >> - Ralph >>=20 >>=20 >>=20 >> _______________________________________________ >> fun mailing list >> fun@ietf.org >> https://www.ietf.org/mailman/listinfo/fun >>=20 > _______________________________________________ > fun mailing list > fun@ietf.org > https://www.ietf.org/mailman/listinfo/fun From rdroms@cisco.com Tue Jun 28 07:41:23 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E8DA11E810F; Tue, 28 Jun 2011 07:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AC2uWRyzEN0m; Tue, 28 Jun 2011 07:41:23 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 0912C11E8118; Tue, 28 Jun 2011 07:41:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rdroms@cisco.com; l=1856; q=dns/txt; s=iport; t=1309272082; x=1310481682; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=L+ttTHWd7+MOZGdm0Zliv11xtYbU18yINxKpI/hk17Y=; b=C0pf3fyiRv+Bt/rk82LZjRUgo5pHTn4AriUtDIdiaJdZGPEH1Zw48cuf AdQ4W6R/IB14DBwkXQT8usPTazOYFw7umR1LR2tIBKnMaOgkt6oKbEFqq iutvD7aNjPJZrY5USyrJGp6JVOCbwMdRCfjuUuUQk2ZTql8xbmrDk7+dI 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAJrnCU6rRDoH/2dsb2JhbABSp0F3iHeie545hjAEkhCQPQ X-IronPort-AV: E=Sophos;i="4.65,437,1304294400"; d="scan'208";a="471303281" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 28 Jun 2011 14:41:22 +0000 Received: from bxb-rdroms-8718.cisco.com (bxb-rdroms-8718.cisco.com [10.98.10.89]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5SEfLJt017246; Tue, 28 Jun 2011 14:41:21 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ralph Droms X-Priority: 3 In-Reply-To: <2184F014-FEAD-4958-843F-8ED099D0A320@cisco.com> Date: Tue, 28 Jun 2011 10:41:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <132C803F-1EF2-40C8-9322-DB5B0D9C4012@cisco.com> References: <4E031DCD.1010606@piuha.net> <3078175EB93B4A4C95E7ACC5F7701D77@china.huawei.com> <2184F014-FEAD-4958-843F-8ED099D0A320@cisco.com> To: Spencer Dawkins X-Mailer: Apple Mail (2.1084) Cc: ipdir@ietf.org, IAB IAB , IESG IESG , fun@ietf.org Subject: Re: [fun] [IAB] Revised homenet charter for IESG consideration X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 14:41:23 -0000 On Jun 28, 2011, at 10:34 AM 6/28/11, Mark Townsley wrote: >=20 > Thanks Spencer. For my part, I have no problem with your proposed = text. Fine with me, too... - Ralph >=20 > - Mark >=20 > On Jun 28, 2011, at 4:23 PM, Spencer Dawkins wrote: >=20 >> Dear INT ADs, >>=20 >> I don't want to interrupt the food fight just to ask someone to pass = the salt, but ... :D >>=20 >> The current (last I saw) proposed charter for HOMENET didn't seem = quite clear enough that having "as few subnets as possible" doesn't make = the complexity of having multiple subnets go away. I was hoping that = this could be stated a little more bluntly. >>=20 >> Could I suggest something like >>=20 >> OLD: o Multiple segments: While less complex L3-toplogies involving = as few >> subnets as possible are preferred in home networks for a variety of >> reasons including simpler management and service discovery, >> incorporation of dedicated segments remain necessary for some >> cases. For instance, ... (excellent reasons deleted because I wasn't = questioning them) >>=20 >> NEW: o Multiple segments: While less complex L3-toplogies involving = as few subnets as possible are preferred in home networks for a variety = of reasons including simpler management and service discovery, the = introduction of more than one subnet into a home network is enough to = add complexity that needs to be addressed, and multiple dedicated = segments are necessary for some cases. For instance, ... (excellent = reasons remain unchanged) >>=20 >> I hope this is a helpful comment, because I don't want to derail the = general conversation by saying something NOT helpful. >>=20 >> Spencer=20 >> _______________________________________________ >> fun mailing list >> fun@ietf.org >> https://www.ietf.org/mailman/listinfo/fun >=20 From jari.arkko@piuha.net Wed Jun 29 00:30:28 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE7C21F86B2; Wed, 29 Jun 2011 00:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.248 X-Spam-Level: X-Spam-Status: No, score=-101.248 tagged_above=-999 required=5 tests=[AWL=-0.949, BAYES_00=-2.599, MANGLED_MARKET=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IBojA0gQYcpy; Wed, 29 Jun 2011 00:30:28 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id E18E321F86B1; Wed, 29 Jun 2011 00:30:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id A9D952CC3B; Wed, 29 Jun 2011 10:30:25 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 54eG0TaQrxaM; Wed, 29 Jun 2011 10:30:22 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 69DD52CC39; Wed, 29 Jun 2011 10:30:17 +0300 (EEST) Message-ID: <4E0AD489.7020002@piuha.net> Date: Wed, 29 Jun 2011 09:30:17 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Mark Townsley References: <4E031DCD.1010606@piuha.net> <3A1DC425-BF54-4CD1-A7D4-5AF668680DB5@amalfisystems.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipdir@ietf.org" , IAB , IESG , "fun@ietf.org" Subject: Re: [fun] Revised homenet charter for IESG consideration X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 07:30:28 -0000 Randy, Mark, et al -- I agree about the without active administration part, of course. But was there a change in the charter text that you wanted based on this exchange? Jari Mark Townsley kirjoitti: > On Jun 28, 2011, at 4:06 PM, Randy Turner wrote: > > >> "without active administration" should probably be the goal regardless of topology.., >> > > +1 > > - Mark > > From jari.arkko@piuha.net Wed Jun 29 00:35:43 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60CA621F86B4; Wed, 29 Jun 2011 00:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.303 X-Spam-Level: X-Spam-Status: No, score=-102.303 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t5Tx4BBUAsr0; Wed, 29 Jun 2011 00:35:43 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id D7B1721F85CA; Wed, 29 Jun 2011 00:35:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id E45092CC3B; Wed, 29 Jun 2011 10:35:41 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFHJn0y31Ce5; Wed, 29 Jun 2011 10:35:39 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 317B92CC39; Wed, 29 Jun 2011 10:35:37 +0300 (EEST) Message-ID: <4E0AD5C8.4030406@piuha.net> Date: Wed, 29 Jun 2011 09:35:36 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Mark Townsley , Spencer Dawkins References: <4E031DCD.1010606@piuha.net> <3078175EB93B4A4C95E7ACC5F7701D77@china.huawei.com> <2184F014-FEAD-4958-843F-8ED099D0A320@cisco.com> In-Reply-To: <2184F014-FEAD-4958-843F-8ED099D0A320@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipdir@ietf.org, 'IAB' , 'IESG' , fun@ietf.org Subject: Re: [fun] [ipdir] [IAB] Revised homenet charter for IESG consideration X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 07:35:43 -0000 Spencer, Mark: Agreed. I have made this change to the current copy of the charter. Thanks. Jari From jari.arkko@piuha.net Wed Jun 29 00:46:26 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF0921F8708 for ; Wed, 29 Jun 2011 00:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.33 X-Spam-Level: X-Spam-Status: No, score=-102.33 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VyQhe3bGPntG for ; Wed, 29 Jun 2011 00:46:26 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id ED61521F86C3 for ; Wed, 29 Jun 2011 00:46:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 08C602CC3B; Wed, 29 Jun 2011 10:46:25 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7DMP9t0yyMh; Wed, 29 Jun 2011 10:46:23 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 983EE2CC39; Wed, 29 Jun 2011 10:46:22 +0300 (EEST) Message-ID: <4E0AD84C.5030207@piuha.net> Date: Wed, 29 Jun 2011 09:46:20 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Paul Hoffman References: <16CD5318-7161-47D6-AB7C-7C240097B0F3@vpnc.org> In-Reply-To: <16CD5318-7161-47D6-AB7C-7C240097B0F3@vpnc.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: fun@ietf.org Subject: Re: [fun] Any signs of life here? X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 07:46:26 -0000 Paul, > It looks like the BoF is scheduled (under then name "homenet") for Quebec. However, the charter discussion seems to have fizzled out. Just wondering... > There has been quite a bit of discussion, though unfortunately some of that has been on the IESG/IAB lists, and only some here. We should move all the discussion here (and we have, as you can see from some later posts). Jari From jari.arkko@piuha.net Wed Jun 29 01:35:32 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB7F21F8577 for ; Wed, 29 Jun 2011 01:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.053 X-Spam-Level: X-Spam-Status: No, score=-102.053 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GqYacV6kMvI0 for ; Wed, 29 Jun 2011 01:35:31 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 1C13A21F8575 for ; Wed, 29 Jun 2011 01:35:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id B31B52CC3B for ; Wed, 29 Jun 2011 11:35:29 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PoVNuJxs1Oxj for ; Wed, 29 Jun 2011 11:35:28 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 1A4FF2CC39 for ; Wed, 29 Jun 2011 11:35:28 +0300 (EEST) Message-ID: <4E0AE3CF.2070504@piuha.net> Date: Wed, 29 Jun 2011 10:35:27 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: "fun@ietf.org" Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: [fun] status of the homenet effort X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 08:35:32 -0000 I wanted to provide an update of the situation with this working group proposal. HOMENET is a new working group proposal, a variation of the HOMEGATE/HOMENET theme that we discussed last year, but this time looking at it from a different angle. The old effort was mostly focused about what home gateways should do: forwarding, transport, and DNS proxying issues. The new effort is about home networks themselves, in particular what kind of network architecture and configuration is necessary to support IPv6-based home networks. We view IPv4-based home networks as "done" at this time (or perhaps as "cannot be changed anyway"). I have been discussing this effort in the background for the last couple of month with Mark Townsley and others, and more publicly since early June. The proposal has been brought to the IESG, IAB and some directorates for discussion, and we've been going back and forth whether this is ready to become a working group or needs to be run as a BOF in Quebec City. The current plan is that the working group proposal goes to IETF-wide review this week, and if the feedback from the community, IAB, and the IESG is positive, we will create the working group just in time for the IETF. Otherwise, the slot reserved in the agenda for the meeting will be used to run the proposal as a BOF. In any case, I would like to solicit discussion on this topic, and perhaps some early drafts as well. Please comment on the charter at least. Note that the new proposal was called FUN at the time that we created the list. It has now been renamed back to HOMENET to be more descriptive. The list will be renamed soon as well (current subscribers will stay). This is the most recent version of the charter we should discuss: Home Networks (homenet) ----------------------------------- Current Status: Proposed Last Edit: Wednesday, June 29th, 2011 Chairs: TBD Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Routing Area Technical Advisor: TBD Security Area Technical Advisor: TBD Mailing Lists: General Discussion: fun@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/fun Archive: http://www.ietf.org/mail-archive/web/fun Description of Working Group: This working group focuses on the evolving networking technology within and among relatively small “residential home” networks. For example, an obvious trend in home networking is the proliferation of networking technology in an increasingly broad range and number of devices. This evolution in scale and diversity sets some requirements on IETF protocols. Some of the relevant trends include: o Multiple segments: While less complex L3-toplogies involving as few subnets as possible are preferred in home networks for a variety of reasons including simpler management and service discovery, the introduction of more than one subnet into a home network is enough to add complexity that needs to be addressed, and multiple dedicated segments are necessary for some cases. For instance, a common feature in modern home routers in the ability to support both guest and private network segments. Also, link layer networking technology is poised to become more heterogeneous, as networks begin to employ both traditional Ethernet technology and link layers designed for low-powered sensor networks. Finally, similar needs for segmentation may occur in other cases, such as separating building control or corporate extensions from the Internet access network. Different segments may be associated with subnets that have different routing and security policies. o Service providers are deploying IPv6, and support for IPv6 is increasingly available in home gateway devices. While IPv6 resembles IPv4 in many ways, it changes address allocation principles and allows direct IP addressability and routing to devices in the home from the Internet. This is a promising area in IPv6 that has proved challenging in IPv4 with the proliferation of NAT. o End-to-end communication is both an opportunity and a concern as it enables new applications but also exposes nodes in the internal networks to receipt of unwanted traffic from the Internet. Firewalls that restrict incoming connections may be used to prevent exposure, however, this reduces the efficacy of end-to-end connectivity that IPv6 has the potential to restore. Home networks need to provide the tools to handle these situations in a manner accessible to all users of home networks. Manual configuration is rarely, if at all, possible. The purpose of this working group is to focus on this evolution, in particular as it addresses the introduction of IPv6, by developing an architecture addressing this full scope of requirements: o prefix configuration for routers o managing routing o name resolution o service discovery o network security The task of the group is to produce an architecture document that outlines how to construct home networks involving multiple routers and subnets. This document is expected to apply the IPv6 addressing architecture, prefix delegation, global and ULA addresses, source address selection rules and other existing components of the IPv6 architecture. The architecture document should drive what protocols changes, if any, are necessary. Specific protocol work described below is expected to be within the scope of the working group one the architecture work is complete. However, the group is required to review its charter and milestones with the IESG and IETF community before submitting documents that make protocol changes. It is expected that the group has to discuss some of the below solutions, however, in order to complete the architecture work. The group will apply existing protocols to handle the five requirements above. For prefix configuration, existing protocols are likely sufficient, and at worst may need some small enhancements, such as new options. For automatic routing, it is expected that existing routing protocols can be used as is, however, a new mechanism may be needed in order to turn a selected protocol on by default. For name resolution and service discovery, extensions to existing multicast-based name resolution protocols are needed to enable them to work across subnets. For network security, the group shall document the concept of "advanced security" as a further development of "simple security" from RFC 6092. The main goal of this work is to enable a security policy that adapts to IPv6 threats as they emerge, taking into account not only traffic from the Internet at large, but within and leaving the home network itself. It is expected that the working group will define a set of protocol specifications to accomplish the five requirements from above. However, it is not in the scope of the working group to define entirely new routing protocols or address allocation protocols. As noted, additional options or other small extensions may be necessary to use the existing protocols in these new configuration tasks. The working group shall also not make any changes to IPv6 protocols or addressing architecture. Prefix configuration, routing, and security related work shall not cause any changes that are not backwards compatible to existing IPv6 hosts. There may be host visible changes in the work on naming and discovery protocols, however. In its design, the working group shall also consider security aspects and the impact on manageability. The main focus of the working group is home networks, but the group's results may also find applications in other small networks. The working group will liaise with the relevant IETF working groups. In particular, the group should work closely with the V6OPS working group, review any use or extension of DHCP with the DHC working group, and work with additional DNS requirements with the DNSEXT and DNSOP working groups. If it turns out that additional options are needed for a routing protocol, they will be developed in the appropriate Routing Area working group, with the HOMENET working group providing the architecture and requirements for such enhancements. The working group will also liase with external standards bodies where it is expected that there are normative dependencies between the specifications of the two bodies. It is expected that in the architecture definition stage liaising with the Broadband Forum, DLNA, and UPnP Forum is necessary. Milestones: Jul 2011 Formation of the working group Sep 2011 First WG draft on the architecture Dec 2011 Submission of the architecture draft to the IESG as Informational RFC Dec 2011 Charter re-evaluation based on the architecture work Dec 2011 First WG draft on prefix configuration Dec 2011 First WG draft on routing Jan 2012 First WG draft on name resolution Feb 2012 First WG draft on service discovery Feb 2012 First WG draft on perimeter security Feb 2012 Start of routing related work in the relevant routing area working group, if needed Mar 2012 Submission of the prefix configuration draft to the IESG as Standards Track RFC Apr 2012 Submission of the routing draft to the IESG as Informational RFC Sep 2012 Submission of the name resolution draft to the IESG as Standards Track RFC Nov 2012 Submission of the service discovery draft to the IESG as Standards Track RFC Dec 2012 Submission of the perimeter security draft to the IESG as Informational RFC From mark@townsley.net Wed Jun 29 02:46:10 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 225DF21F86B0; Wed, 29 Jun 2011 02:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1pjdhQ9vHom; Wed, 29 Jun 2011 02:46:09 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7246421F86AE; Wed, 29 Jun 2011 02:46:08 -0700 (PDT) Received: by wwe5 with SMTP id 5so708448wwe.13 for ; Wed, 29 Jun 2011 02:46:07 -0700 (PDT) Received: by 10.227.55.20 with SMTP id s20mr539372wbg.15.1309340766348; Wed, 29 Jun 2011 02:46:06 -0700 (PDT) Received: from ams-townsley-8714.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id o19sm773725wbh.38.2011.06.29.02.46.04 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 29 Jun 2011 02:46:05 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1084) From: Mark Townsley In-Reply-To: <4E0AE3CF.2070504@piuha.net> Date: Wed, 29 Jun 2011 11:46:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <98D97264-A266-41FB-9913-A48A7105F73F@townsley.net> References: <4E0AE3CF.2070504@piuha.net> To: fun@ietf.org, homegate@ietf.org X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Wed, 29 Jun 2011 14:25:45 -0700 Subject: Re: [fun] status of the homenet effort X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 09:46:10 -0000 All, Apologies for double-posting if there are folks that are subscribed to = homegate@ietf.org and fun@ietf.org. I'm hoping soon that someone will = finally create homenet@ietf.org and consolidate the membership = accordingly. In the charter proposal below, I think you will see a lot of similarity = with the consensus we achieved on the homegate list last year. Jari has = taken that, feedback from the IESG, IAB, members of the IP-Directorate, = v6ops chairs, etc. and shaped it towards something more focused on the = Internet (and Routing) area, as well as IPv6. I believe he and Ralph = both have a great deal of confidence that this is something that is very = important to the industry, and that the IETF has a critical role to = play.=20 So, make no mistake, whether we end up as a WG or a BoF between now and = Quebec, "we're back" - please send comments, and make your travel or = remote-attendance plans accordingly if you want to participate.=20 Jari has asked me to co-chair the session in Quebec. As such, I'd like = to take requests for presentation time now. Jari and I will likely begin = the session with a scoping overview, as well as a first cut at an = architecture framework, but there should be some time for a few other = items. When submitting your request, please identify which of the 5 = areas below you think your work applies to as well as the = internet-draft, of course.=20 Thanks, and see you on the list and in Quebec. - Mark On Jun 29, 2011, at 10:35 AM, Jari Arkko wrote: > I wanted to provide an update of the situation with this working group = proposal. >=20 > HOMENET is a new working group proposal, a variation of the = HOMEGATE/HOMENET theme that we discussed last year, but this time = looking at it from a different angle. The old effort was mostly focused = about what home gateways should do: forwarding, transport, and DNS = proxying issues. The new effort is about home networks themselves, in = particular what kind of network architecture and configuration is = necessary to support IPv6-based home networks. We view IPv4-based home = networks as "done" at this time (or perhaps as "cannot be changed = anyway"). >=20 > I have been discussing this effort in the background for the last = couple of month with Mark Townsley and others, and more publicly since = early June. The proposal has been brought to the IESG, IAB and some = directorates for discussion, and we've been going back and forth whether = this is ready to become a working group or needs to be run as a BOF in = Quebec City. The current plan is that the working group proposal goes to = IETF-wide review this week, and if the feedback from the community, IAB, = and the IESG is positive, we will create the working group just in time = for the IETF. Otherwise, the slot reserved in the agenda for the meeting = will be used to run the proposal as a BOF. >=20 > In any case, I would like to solicit discussion on this topic, and = perhaps some early drafts as well. Please comment on the charter at = least. >=20 > Note that the new proposal was called FUN at the time that we created = the list. It has now been renamed back to HOMENET to be more = descriptive. The list will be renamed soon as well (current subscribers = will stay). >=20 > This is the most recent version of the charter we should discuss: >=20 > Home Networks (homenet) > ----------------------------------- >=20 > Current Status: Proposed > Last Edit: Wednesday, June 29th, 2011 >=20 > Chairs: > TBD >=20 > Internet Area Directors: > Ralph Droms > Jari Arkko >=20 > Internet Area Advisor: > Jari Arkko >=20 > Routing Area Technical Advisor: > TBD >=20 > Security Area Technical Advisor: > TBD >=20 > Mailing Lists: > General Discussion: fun@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/fun > Archive: http://www.ietf.org/mail-archive/web/fun >=20 > Description of Working Group: >=20 > This working group focuses on the evolving networking technology > within and among relatively small =93residential home=94 networks. For > example, an obvious trend in home networking is the proliferation of > networking technology in an increasingly broad range and number of > devices. This evolution in scale and diversity sets some requirements > on IETF protocols. Some of the relevant trends include: >=20 > o Multiple segments: While less complex L3-toplogies involving as few > subnets as possible are preferred in home networks for a variety of > reasons including simpler management and service discovery, the > introduction of more than one subnet into a home network is enough > to add complexity that needs to be addressed, and multiple > dedicated segments are necessary for some cases. For instance, a > common feature in modern home routers in the ability to support > both guest and private network segments. Also, link layer > networking technology is poised to become more heterogeneous, as > networks begin to employ both traditional Ethernet technology and > link layers designed for low-powered sensor networks. Finally, > similar needs for segmentation may occur in other cases, such as > separating building control or corporate extensions from the > Internet access network. Different segments may be associated with > subnets that have different routing and security policies. >=20 > o Service providers are deploying IPv6, and support for IPv6 is > increasingly available in home gateway devices. While IPv6 resembles > IPv4 in many ways, it changes address allocation principles and allows > direct IP addressability and routing to devices in the home from the > Internet. This is a promising area in IPv6 that has proved challenging > in IPv4 with the proliferation of NAT. >=20 > o End-to-end communication is both an opportunity and a concern as it > enables new applications but also exposes nodes in the internal > networks to receipt of unwanted traffic from the Internet. Firewalls > that restrict incoming connections may be used to prevent exposure, > however, this reduces the efficacy of end-to-end connectivity that > IPv6 has the potential to restore. >=20 > Home networks need to provide the tools to handle these situations in > a manner accessible to all users of home networks. Manual > configuration is rarely, if at all, possible. The purpose of this > working group is to focus on this evolution, in particular as it > addresses the introduction of IPv6, by developing an architecture > addressing this full scope of requirements: >=20 > o prefix configuration for routers > o managing routing > o name resolution > o service discovery > o network security >=20 > The task of the group is to produce an architecture document that > outlines how to construct home networks involving multiple routers and > subnets. This document is expected to apply the IPv6 addressing > architecture, prefix delegation, global and ULA addresses, source > address selection rules and other existing components of the IPv6 > architecture. The architecture document should drive what protocols > changes, if any, are necessary. Specific protocol work described below > is expected to be within the scope of the working group one the > architecture work is complete. However, the group is required to > review its charter and milestones with the IESG and IETF community > before submitting documents that make protocol changes. It is expected > that the group has to discuss some of the below solutions, however, in > order to complete the architecture work. >=20 > The group will apply existing protocols to handle the five > requirements above. For prefix configuration, existing protocols are > likely sufficient, and at worst may need some small enhancements, such > as new options. For automatic routing, it is expected that existing > routing protocols can be used as is, however, a new mechanism may be > needed in order to turn a selected protocol on by default. For name > resolution and service discovery, extensions to existing > multicast-based name resolution protocols are needed to enable them to > work across subnets. >=20 > For network security, the group shall document the concept of > "advanced security" as a further development of "simple security" from > RFC 6092. The main goal of this work is to enable a security policy > that adapts to IPv6 threats as they emerge, taking into account not > only traffic from the Internet at large, but within and leaving the > home network itself. >=20 > It is expected that the working group will define a set of protocol > specifications to accomplish the five requirements from > above. However, it is not in the scope of the working group to define > entirely new routing protocols or address allocation protocols. As > noted, additional options or other small extensions may be necessary > to use the existing protocols in these new configuration tasks. The > working group shall also not make any changes to IPv6 protocols or > addressing architecture. Prefix configuration, routing, and security > related work shall not cause any changes that are not backwards > compatible to existing IPv6 hosts. There may be host visible changes > in the work on naming and discovery protocols, however. In its design, > the working group shall also consider security aspects and the impact > on manageability. The main focus of the working group is home > networks, but the group's results may also find applications in other > small networks. >=20 > The working group will liaise with the relevant IETF working > groups. In particular, the group should work closely with the V6OPS > working group, review any use or extension of DHCP with the DHC > working group, and work with additional DNS requirements with the > DNSEXT and DNSOP working groups. If it turns out that additional > options are needed for a routing protocol, they will be developed in > the appropriate Routing Area working group, with the HOMENET working > group providing the architecture and requirements for such > enhancements. The working group will also liase with external > standards bodies where it is expected that there are normative > dependencies between the specifications of the two bodies. > It is expected that in the architecture definition stage liaising > with the Broadband Forum, DLNA, and UPnP Forum is necessary. >=20 > Milestones: >=20 > Jul 2011 Formation of the working group > Sep 2011 First WG draft on the architecture > Dec 2011 Submission of the architecture draft to the IESG as = Informational RFC > Dec 2011 Charter re-evaluation based on the architecture work > Dec 2011 First WG draft on prefix configuration > Dec 2011 First WG draft on routing > Jan 2012 First WG draft on name resolution > Feb 2012 First WG draft on service discovery > Feb 2012 First WG draft on perimeter security > Feb 2012 Start of routing related work in the relevant routing area = working group, if needed > Mar 2012 Submission of the prefix configuration draft to the IESG as = Standards Track RFC > Apr 2012 Submission of the routing draft to the IESG as Informational = RFC > Sep 2012 Submission of the name resolution draft to the IESG as = Standards Track RFC > Nov 2012 Submission of the service discovery draft to the IESG as = Standards Track RFC > Dec 2012 Submission of the perimeter security draft to the IESG as = Informational RFC >=20 > _______________________________________________ > fun mailing list > fun@ietf.org > https://www.ietf.org/mailman/listinfo/fun From jari.arkko@piuha.net Thu Jun 30 02:32:01 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D403221F87AC; Thu, 30 Jun 2011 02:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.999 X-Spam-Level: X-Spam-Status: No, score=-100.999 tagged_above=-999 required=5 tests=[AWL=-1.154, BAYES_00=-2.599, FRT_BELOW2=2.154, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PjqqXe1daLkB; Thu, 30 Jun 2011 02:32:01 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id CEA2C21F87AB; Thu, 30 Jun 2011 02:32:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 7FAC02CEA0; Thu, 30 Jun 2011 12:31:58 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LV2mS+CqafKu; Thu, 30 Jun 2011 12:31:57 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 069AB2CC39; Thu, 30 Jun 2011 12:31:56 +0300 (EEST) Message-ID: <4E0C428D.1070508@piuha.net> Date: Thu, 30 Jun 2011 11:31:57 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Fernando Gont References: <4E0AE696.4020603@piuha.net> <4E0BDCF3.1090003@gont.com.ar> In-Reply-To: <4E0BDCF3.1090003@gont.com.ar> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "fun@ietf.org" , IETF Discussion Subject: Re: [fun] HOMENET working group proposal X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 09:32:02 -0000 Fernando, First off, I'm switching the reply headers to fun@ietf.org now, deleting the old homegate list from this discussion. Secondly, I would like to explain the motivation behind focusing this work on IPv6. Its not so much about IPv6 being different (though I hope it is in some respects). The reason why I want this working group to focus on IPv6 is that I don't think new IETF work would have much effect on IPv4 home network architecture. Whereas I think we have a good chance of having an effect in the IPv6 case, given that there is not much deployed base yet in home routers, consumer ISPs, etc. Finally, I don't think we need to take a black-and-white approach to discussing the end-to-end model. Obviously we know about the V6OPS simple security work. Of course there are firewalls in IPv6, restricting incoming traffic. That being said, I think the right architecture for IPv6 home networks is that incoming traffic is restricted *by policy* on a per-need basis, not by an addressing design that forever prevents us from allowing specific incoming protocols. This is what we mean by architecture specification from this working group. Practical network design that does the right thing and lets people do what they want -- not a requirement to open your network up for anything. Jari Fernando Gont kirjoitti: > Hi, Jari, > > My high level comment/question is: the proposed charter seems to stress > that IPv6 is the driver behind this potential wg effort... however, Ie > think that this deserves more discussion -- it's not clear to me why/how > typical IPv6 home networks would be much different from their IPv4 > counterparts. > > Bellow you'll find some comments/questions about the proposed charter. > They are not an argument against or in favour of the creation of the > aforementioned wg, but rather comments and/or requests for clarification... > > On 06/29/2011 05:47 AM, Jari Arkko wrote: > [....] > >> o Service providers are deploying IPv6, and support for IPv6 is >> increasingly available in home gateway devices. While IPv6 resembles >> IPv4 in many ways, it changes address allocation principles and allows >> direct IP addressability and routing to devices in the home from the >> Internet. This is a promising area in IPv6 that has proved challenging >> in IPv4 with the proliferation of NAT. >> > > NAT devices involve two related but different issues: > * address translation > * an implicit "allow only return traffic" firewall-like functionality > > One would hope/expect that the former will be gone with IPv6. However, I > don't think the latter will. As a result, even when you could "address" > nodes that belong to the "home network", you probably won't be able to > get your packets to them, unless those nodes initiated the communication > instance. > > For instance (and of the top of my head), this functionality is even > proposed in the "simple security" requirements that had been produced by > v6ops. > > > >> o End-to-end communication is both an opportunity and a concern as it >> enables new applications but also exposes nodes in the internal >> networks to receipt of unwanted traffic from the Internet. Firewalls >> that restrict incoming connections may be used to prevent exposure, >> however, this reduces the efficacy of end-to-end connectivity that >> IPv6 has the potential to restore. >> > > I personally consider this property of "end-to-end connectivity" as > "gone". -- among other reasons, because it would require a change of > mindset. I'm more of the idea that people will replicate the > architecture of their IPv4 networks with IPv6, in which end-systems are > not reachable from the public Internet. > > Thanks! > From jari.arkko@piuha.net Thu Jun 30 02:38:33 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C14D221F87B6; Thu, 30 Jun 2011 02:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.332 X-Spam-Level: X-Spam-Status: No, score=-102.332 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEhl9kJXpTwR; Thu, 30 Jun 2011 02:38:33 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id E88CD21F863B; Thu, 30 Jun 2011 02:38:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 1DB0E2D3FA; Thu, 30 Jun 2011 12:38:32 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYnOoFUyKm0M; Thu, 30 Jun 2011 12:38:31 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 1D3E42CC39; Thu, 30 Jun 2011 12:38:31 +0300 (EEST) Message-ID: <4E0C4417.90804@piuha.net> Date: Thu, 30 Jun 2011 11:38:31 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Fernando Gont References: <4E0AE696.4020603@piuha.net> <4E0BDCF3.1090003@gont.com.ar> <4E0C1CF8.7090601@gont.com.ar> In-Reply-To: <4E0C1CF8.7090601@gont.com.ar> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF Discussion , "fun@ietf.org" Subject: Re: [fun] [homegate] HOMENET working group proposal X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 09:38:33 -0000 Fernando, > My point was that, except for the mechanism for PD, I don't see a > substantial difference here that would e.g. prevent this from being > developed for IPv4 (in addition to IPv6). -- Yes, I know we need to > deploy IPv6... but I don't think you can expect people to get rid of > their *working* IPv4 devices... (i.e., not sure why any of this > functionality should be v6-only) > You have to separate IETF specifications and functionality of real-world products. Obviously everyone is going to have IPv4 based home networks for a long time. But their architecture is largely done and cannot be easily affected. Vendors are now looking into adding IPv6 into their home routers and other devices. I want to be able to show them how to do it right. They can, of course, replicate everything exactly as in IPv4. Much of it is right, of course, but on some areas I think we can do better. This is why the working group should focus on IPv6. If the group is successful, IPv4 network design continues to be what it is, but our recommendations for the IPv6 network design are adopted by vendors' home devices. Jari From fernando.gont.netbook.win@gmail.com Thu Jun 30 02:47:49 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F049521F87B5; Thu, 30 Jun 2011 02:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.359 X-Spam-Level: X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5KRPAydaRArx; Thu, 30 Jun 2011 02:47:49 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 51E3221F87B4; Thu, 30 Jun 2011 02:47:49 -0700 (PDT) Received: by yie30 with SMTP id 30so1034469yie.31 for ; Thu, 30 Jun 2011 02:47:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=wuvzIDIejO+ynETTjiGZm6BT1MUsU5YUgJqth0FZQjo=; b=jsmfR98hhFZZ2C5vgTwPiNr8ebaH+gvkRe6Q1Fdwt+XnaGsno9DlFm2ZeklgIPnj5y zUFpGYlFRjcnhxYpSuICOypAdWGmSw7XdZXLpU1XcwgM6LiUMiE1QfqvRf4euNt6BlPH KdQeco3X73pHXd4N82Gd+uV59rJ+h8Ln+RYv8= Received: by 10.101.179.12 with SMTP id g12mr1549559anp.59.1309427268734; Thu, 30 Jun 2011 02:47:48 -0700 (PDT) Received: from [192.168.123.103] ([190.48.255.131]) by mx.google.com with ESMTPS id x4sm1859142anp.17.2011.06.30.02.47.43 (version=SSLv3 cipher=OTHER); Thu, 30 Jun 2011 02:47:47 -0700 (PDT) Sender: Fernando Gont Message-ID: <4E0C4631.3010409@gont.com.ar> Date: Thu, 30 Jun 2011 06:47:29 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: Jari Arkko References: <4E0AE696.4020603@piuha.net> <4E0BDCF3.1090003@gont.com.ar> <4E0C1CF8.7090601@gont.com.ar> <4E0C4417.90804@piuha.net> In-Reply-To: <4E0C4417.90804@piuha.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF Discussion , "fun@ietf.org" Subject: Re: [fun] [homegate] HOMENET working group proposal X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 09:47:50 -0000 Jari, On 06/30/2011 06:38 AM, Jari Arkko wrote: > But their architecture is largely done and cannot be easily affected. > Vendors are now looking into adding IPv6 into their home routers and > other devices. I want to be able to show them how to do it right. They > can, of course, replicate everything exactly as in IPv4. Much of it is > right, of course, but on some areas I think we can do better. This is > why the working group should focus on IPv6. My point is: Will implementation of the produced RFCs lead to home networks in which stuff works for IPv6 differently from how it works for IPv4? e.g., your home network would have multiple subnets (thanks to PD), but a single IPv4 subnet? If our work focuses only on IPv6, I get the impression that we're heading in that direction. If HOMENET is going to improve stuff that we already do with IPv4 (by leveraging IPv6), then that's fine... but not what I read from this discussion and the proposed charter. Thoughts? Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From mark@townsley.net Thu Jun 30 02:57:12 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC6721F8765; Thu, 30 Jun 2011 02:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMCF1xRJkbPN; Thu, 30 Jun 2011 02:57:12 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 667EF21F8718; Thu, 30 Jun 2011 02:57:11 -0700 (PDT) Received: by wyj26 with SMTP id 26so1629381wyj.31 for ; Thu, 30 Jun 2011 02:57:10 -0700 (PDT) Received: by 10.227.195.13 with SMTP id ea13mr1680580wbb.0.1309427830425; Thu, 30 Jun 2011 02:57:10 -0700 (PDT) Received: from ams-townsley-8714.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id ex2sm1506729wbb.14.2011.06.30.02.57.07 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 30 Jun 2011 02:57:08 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Mark Townsley In-Reply-To: Date: Thu, 30 Jun 2011 11:57:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <558D0669-8B2A-4514-B3FB-C690C40A4EF8@townsley.net> References: <4E0AE696.4020603@piuha.net> <4E0BDCF3.1090003@gont.com.ar> <4E0C1CF8.7090601@gont.com.ar> To: homegate@ietf.org, IETF Discussion , fun@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [fun] [homegate] HOMENET working group proposal X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 09:57:12 -0000 I think the consensus we had in the past BoFs and discussion in and = around this topic can be summed up as stating that homenet deliverables = will: - coexist with (existing) IPv4 protocols, devices, applications, etc. - operate in a (future) IPv6-only home network in the absence of IPv4 - be IP-agnostic whenever possible In other words, anything we do for the IPv6 homenet cannot actively = break what's already running on IPv4. Also, trying to define what the = IPv4 home network should be has long reached a point of diminishing = returns given the effort in doing so coupled with our ability to = significantly affect what's already deployed. There's still hope we can = help direct IPv6, as such that is homenet's primary focus. However, = when we can define something that is needed for IPv6 in a way that is = also useful for IPv4 without making significant concessions, we should = go ahead and do so.=20 - Mark On Jun 30, 2011, at 9:25 AM, Mikael Abrahamsson wrote: > On Thu, 30 Jun 2011, Fernando Gont wrote: >=20 >> My point was that, except for the mechanism for PD, I don't see a = substantial difference here that would e.g. prevent this from being = developed for IPv4 (in addition to IPv6). -- Yes, I know we need to = deploy IPv6... but I don't think you can expect people to get rid of = their *working* IPv4 devices... (i.e., not sure why any of this = functionality should be v6-only) >=20 > Chaining NAT boxes already work. I also feel that we shouldn't put in = a lot of work to develop IPv4 further, that focus should be put on IPv6. >=20 >> I think this deserves a problem statement that clearly describes what = we expect to be able to do (but currently can't), etc. And, if this is = meant to be v6-only, state why v4 is excluded -- unless we're happy to = have people connect their IPv4-devices, and see that they cannot = communicate anymore. >=20 > IPv4 should be excluded because it's a dead end, and we all know it. = We're just disagreeing when it's going to die and how. >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > homegate mailing list > homegate@ietf.org > https://www.ietf.org/mailman/listinfo/homegate From jari.arkko@piuha.net Thu Jun 30 03:02:58 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E1C421F87AD; Thu, 30 Jun 2011 03:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.342 X-Spam-Level: X-Spam-Status: No, score=-102.342 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7ARBOLY90SB; Thu, 30 Jun 2011 03:02:58 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 0A98721F8737; Thu, 30 Jun 2011 03:02:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 35CCB2CEA0; Thu, 30 Jun 2011 13:02:57 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eb0i9G78I0XA; Thu, 30 Jun 2011 13:02:56 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 2A4B62CC39; Thu, 30 Jun 2011 13:02:55 +0300 (EEST) Message-ID: <4E0C49CD.30505@piuha.net> Date: Thu, 30 Jun 2011 12:02:53 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Fernando Gont References: <4E0AE696.4020603@piuha.net> <4E0BDCF3.1090003@gont.com.ar> <4E0C1CF8.7090601@gont.com.ar> <4E0C4417.90804@piuha.net> <4E0C4631.3010409@gont.com.ar> In-Reply-To: <4E0C4631.3010409@gont.com.ar> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF Discussion , "fun@ietf.org" Subject: Re: [fun] [homegate] HOMENET working group proposal X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 10:02:58 -0000 Fernando, > My point is: Will implementation of the produced RFCs lead to home > networks in which stuff works for IPv6 differently from how it works for > IPv4? That is the plan. And when I say "differently", I mean differences such as * prefix delegation * global addresses and firewalls instead of private addresses and NATs * across-subnet communication internally in the home can be routed, not NATted > e.g., your home network would have multiple subnets (thanks to > PD), but a single IPv4 subnet? > But the examples you cite are not differences we are really aiming at. Multiple subnets is something that generally should be avoided where possible, but cannot be completely avoided. It applies to IPv4 and IPv6 in equal manner, e.g., when you have a Guest and Private SSIDs on your wireless. In this case the difference between IPv4 and IPv6 is merely that in one case we NAT to the Internet and between the two networks, in another case we route/firewall. > If our work focuses only on IPv6, I get the impression that we're > heading in that direction. > > If HOMENET is going to improve stuff that we already do with IPv4 (by > leveraging IPv6), then that's fine... but not what I read from this > discussion and the proposed charter. > My point is that I don't think we can change the IPv4 situation. We can affect the way IPv6 is used. Maybe we can even make things better in IPv6 than they were in IPv4. So in the end the user experience may improve for people who use IPv6, but it is definitely not our goal to improve IPv4. Jari From fernando.gont.netbook.win@gmail.com Thu Jun 30 03:40:25 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03B9B21F882D; Thu, 30 Jun 2011 03:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.413 X-Spam-Level: X-Spam-Status: No, score=-3.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pl+ZmQ8mNrlL; Thu, 30 Jun 2011 03:40:24 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id E692121F8822; Thu, 30 Jun 2011 03:40:23 -0700 (PDT) Received: by gxk19 with SMTP id 19so1036878gxk.31 for ; Thu, 30 Jun 2011 03:40:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=ceNvLYYz88AOYiiSc3h3adcXQriY4SadLP/RMKLgZ4c=; b=BPio+iKqZtkPtuYXdBhqLnua+MWBo+V7CkLPLzHZNV3IHd5cPvw8HFXruLgce901jQ mFK6uJLMsBuHuEQKv/60phXtbeuNvSu8TH29MGkxx2Cf+IDPIihGrXqb1mtN5suafcvz rSl8y7wZMSrQPypnpYHs7V1JPdRkrfjn5G4uQ= Received: by 10.101.154.22 with SMTP id g22mr1654733ano.58.1309430423272; Thu, 30 Jun 2011 03:40:23 -0700 (PDT) Received: from [192.168.123.103] ([190.48.255.131]) by mx.google.com with ESMTPS id r19sm1890175and.26.2011.06.30.03.40.20 (version=SSLv3 cipher=OTHER); Thu, 30 Jun 2011 03:40:22 -0700 (PDT) Sender: Fernando Gont Message-ID: <4E0C5291.8030104@gont.com.ar> Date: Thu, 30 Jun 2011 07:40:17 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: Mark Townsley References: <4E0AE696.4020603@piuha.net> <4E0BDCF3.1090003@gont.com.ar> <4E0C1CF8.7090601@gont.com.ar> <558D0669-8B2A-4514-B3FB-C690C40A4EF8@townsley.net> In-Reply-To: <558D0669-8B2A-4514-B3FB-C690C40A4EF8@townsley.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: fun@ietf.org, homegate@ietf.org, IETF Discussion Subject: Re: [fun] [homegate] HOMENET working group proposal X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 10:40:25 -0000 Hi, Mark (and Jari), Thanks so much for your clarification! All my questions/comments have been addressed. Thanks, Fernando On 06/30/2011 06:57 AM, Mark Townsley wrote: > > I think the consensus we had in the past BoFs and discussion in and > around this topic can be summed up as stating that homenet > deliverables will: > > - coexist with (existing) IPv4 protocols, devices, applications, > etc. - operate in a (future) IPv6-only home network in the absence of > IPv4 - be IP-agnostic whenever possible > > In other words, anything we do for the IPv6 homenet cannot actively > break what's already running on IPv4. Also, trying to define what the > IPv4 home network should be has long reached a point of diminishing > returns given the effort in doing so coupled with our ability to > significantly affect what's already deployed. There's still hope we > can help direct IPv6, as such that is homenet's primary focus. > However, when we can define something that is needed for IPv6 in a > way that is also useful for IPv4 without making significant > concessions, we should go ahead and do so. > > - Mark > > > > On Jun 30, 2011, at 9:25 AM, Mikael Abrahamsson wrote: > >> On Thu, 30 Jun 2011, Fernando Gont wrote: >> >>> My point was that, except for the mechanism for PD, I don't see a >>> substantial difference here that would e.g. prevent this from >>> being developed for IPv4 (in addition to IPv6). -- Yes, I know we >>> need to deploy IPv6... but I don't think you can expect people to >>> get rid of their *working* IPv4 devices... (i.e., not sure why >>> any of this functionality should be v6-only) >> >> Chaining NAT boxes already work. I also feel that we shouldn't put >> in a lot of work to develop IPv4 further, that focus should be put >> on IPv6. >> >>> I think this deserves a problem statement that clearly describes >>> what we expect to be able to do (but currently can't), etc. And, >>> if this is meant to be v6-only, state why v4 is excluded -- >>> unless we're happy to have people connect their IPv4-devices, and >>> see that they cannot communicate anymore. >> >> IPv4 should be excluded because it's a dead end, and we all know >> it. We're just disagreeing when it's going to die and how. >> >> -- Mikael Abrahamsson email: swmike@swm.pp.se >> _______________________________________________ homegate mailing >> list homegate@ietf.org >> https://www.ietf.org/mailman/listinfo/homegate > > _______________________________________________ homegate mailing > list homegate@ietf.org > https://www.ietf.org/mailman/listinfo/homegate > -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From pthubert@cisco.com Thu Jun 30 03:53:48 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D73621F86E2; Thu, 30 Jun 2011 03:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.599 X-Spam-Level: X-Spam-Status: No, score=-11.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 qcl0Dhglk7ft; Thu, 30 Jun 2011 03:53:48 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 86A8D21F86AC; Thu, 30 Jun 2011 03:53:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=959; q=dns/txt; s=iport; t=1309431227; x=1310640827; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=F1G4sF0wTufITEnXncVNRIs8Nzlus7JcCeMeWVCvqOw=; b=LHgBC/7ERD835oFC+atOlaWe7KSmIqSX1d3/1kR6W+IVJNJKrZnwv6hy A4mfSbPab/ePmCh209G6rmQ4mE0ZIFewQqWy/sXz8kg0L5UocfV0QUzUe +cFOY/ohfH0N98INqnNNWBRJmKJKSYco+JPcx9rmEqf+QxWo4xFDZde4N E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAP9UDE6Q/khL/2dsb2JhbABSp1N3iHiga54WhjEEly6LMQ X-IronPort-AV: E=Sophos;i="4.65,449,1304294400"; d="scan'208";a="39998362" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 30 Jun 2011 10:53:33 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5UArUSi008338; Thu, 30 Jun 2011 10:53:30 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 30 Jun 2011 12:53:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 30 Jun 2011 12:53:25 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D04FAE6D4@XMB-AMS-107.cisco.com> In-Reply-To: <4E0C49CD.30505@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [fun] [homegate] HOMENET working group proposal Thread-Index: Acw3DOnOo1pL3PujS8ii/5j3somAQQABec+w References: <4E0AE696.4020603@piuha.net> <4E0BDCF3.1090003@gont.com.ar><4E0C1CF8.7090601@gont.com.ar> <4E0C4417.90804@piuha.net><4E0C4631.3010409@gont.com.ar> <4E0C49CD.30505@piuha.net> From: "Pascal Thubert (pthubert)" To: "Jari Arkko" , "Fernando Gont" X-OriginalArrivalTime: 30 Jun 2011 10:53:31.0099 (UTC) FILETIME=[F332A2B0:01CC3713] Cc: IETF Discussion , fun@ietf.org Subject: Re: [fun] [homegate] HOMENET working group proposal X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 10:53:48 -0000 > That is the plan. And when I say "differently", I mean differences such as >=20 > * prefix delegation > * global addresses and firewalls instead of private addresses and NATs > * across-subnet communication internally in the home can be routed, not > NATted >=20 [Pascal] I'd add to that multiple virtual topologies, and heterogeneous subnets where even the link layer is not consistent across the subnet. Automation and command/control already uses wireless technologies that are non WIFI; ISA100.15 already works on backhaul technologies; the IETF is missing a clear model to explain them how we isolate flows and merge heterogeneous links into one subnet.=20 I think there is a lot this group can do to pursue / extend what was done at 6LoWPAN (ND, backbone router) so that the work there connects to the rest of the home, and by extension, the rest of other networks such as building and industrial plants. Cheers, Pascal From fernando.gont.netbook.win@gmail.com Thu Jun 30 06:08:49 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48AE721F86C9; Thu, 30 Jun 2011 06:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.431 X-Spam-Level: X-Spam-Status: No, score=-3.431 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qAid1GG-wRzK; Thu, 30 Jun 2011 06:08:48 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id A5F9721F864A; Thu, 30 Jun 2011 06:08:48 -0700 (PDT) Received: by yie30 with SMTP id 30so1107630yie.31 for ; Thu, 30 Jun 2011 06:08:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=a+C1IXj7Enk8hiutt6kv1oK8LpfnjPM/HzGpHoh9kfo=; b=sNzLZ6/zmmCt5sCjp5148MUTTmBuqjGnKXqjBfx70Oxfyj/WAmgRCOszN7RpMqY/mY WSGuiS2/p2vaiAh15nEyqyeQRSlUgQJr79xEjAQgBKFq8vHQaXbZ1359R86qqGJ19DV7 8eFCojQ4HFAMx7EP/McgPAEimhn9G2xfuUIg0= Received: by 10.101.176.2 with SMTP id d2mr1738637anp.155.1309439328126; Thu, 30 Jun 2011 06:08:48 -0700 (PDT) Received: from [192.168.123.103] ([190.48.255.131]) by mx.google.com with ESMTPS id b19sm1979890anh.19.2011.06.30.06.08.44 (version=SSLv3 cipher=OTHER); Thu, 30 Jun 2011 06:08:47 -0700 (PDT) Sender: Fernando Gont Message-ID: <4E0C70FA.5070300@gont.com.ar> Date: Thu, 30 Jun 2011 09:50:02 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: Keith Moore References: <4E0AE696.4020603@piuha.net> <4E0BDCF3.1090003@gont.com.ar> <4E0C1CF8.7090601@gont.com.ar> <4E0C4417.90804@piuha.net> <4E0C4631.3010409@gont.com.ar> <94830A23-F251-4EDC-8002-11422CF691E2@network-heretics.com> In-Reply-To: <94830A23-F251-4EDC-8002-11422CF691E2@network-heretics.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF Discussion , "fun@ietf.org" Subject: Re: [fun] [homegate] HOMENET working group proposal X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 13:08:49 -0000 On 06/30/2011 09:21 AM, Keith Moore wrote: >> If our work focuses only on IPv6, I get the impression that we're >> heading in that direction. > > nothing says that some results of the work can't also apply to IPv4. > but people are far too mired in outdated assumptions today, such as > the idea that every network needs a NAT or a firewall that filters > based on IP addresses and ports. I did not even argue about ports or addressing, but rather about who initiated the communication instance. >> If HOMENET is going to improve stuff that we already do with IPv4 >> (by leveraging IPv6), then that's fine... > > no, that's not fine. that's painting ourselves (and the Internet) > into a corner. I was mostly referring to not breaking what already works with v4 (i.e., not be a MUST for all devices in a home network to support some v6 feature for the network to work, such that our existing v4-only devices can co-exist in whatever v6 home-network architecture we envision). Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From jason.weil@twcable.com Thu Jun 30 07:14:46 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B034411E813E; Thu, 30 Jun 2011 07:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.137 X-Spam-Level: X-Spam-Status: No, score=0.137 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0Vjwxmscm9o; Thu, 30 Jun 2011 07:14:45 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB4B11E8116; Thu, 30 Jun 2011 07:14:45 -0700 (PDT) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.65,450,1304308800"; d="scan'208";a="230442299" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 30 Jun 2011 10:14:00 -0400 Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.28]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Thu, 30 Jun 2011 10:14:44 -0400 From: "Weil, Jason" To: Mark Townsley , "fun@ietf.org" , "homegate@ietf.org" Date: Thu, 30 Jun 2011 10:14:40 -0400 Thread-Topic: [fun] status of the homenet effort Thread-Index: Acw3MA7DmkJzeqGrTsSV+ZKjWvO5NQ== Message-ID: In-Reply-To: <98D97264-A266-41FB-9913-A48A7105F73F@townsley.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.0.0.100825 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [fun] status of the homenet effort X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 14:14:46 -0000 Mark, Raplh, Jari, et all, I really appreciate the change in charter and direction for this proposed WG and the interest to keep it going. I believe it sets a path that is scoped narrow enough to provide a workplace for achievable results. As a provider working on writing, testing and implementing IPv6 CPE, I can relate firsthand that getting basic IPv6 functionality working in the home network is no simple feat and is still a work in progress. Don't get me wrong, basic functionality is there just not baked. What seems very straightforward in theory typically fails in a multitude of corner cases ie reality. And just to clarify I am referring to a single /64 subnet topology with no routing. If we can stay focussed on solving just the basics for the five areas included, I believe it will be helpful. The other recommendation would be to work as expeditiously as possible. Providers in the process of deploying IPv6 now are already deep into this analysis and development with their vendors. If we wait too long then these topics will be solved with interoperability a possible casualty. FWIW, I would also add that the five topics in the charter are also listed in order Of priority at least for me. Thanks, Jason On 6/29/11 5:46 AM, "Mark Townsley" wrote: > >All, > >Apologies for double-posting if there are folks that are subscribed to >homegate@ietf.org and fun@ietf.org. I'm hoping soon that someone will >finally create homenet@ietf.org and consolidate the membership >accordingly. > >In the charter proposal below, I think you will see a lot of similarity >with the consensus we achieved on the homegate list last year. Jari has >taken that, feedback from the IESG, IAB, members of the IP-Directorate, >v6ops chairs, etc. and shaped it towards something more focused on the >Internet (and Routing) area, as well as IPv6. I believe he and Ralph both >have a great deal of confidence that this is something that is very >important to the industry, and that the IETF has a critical role to play. > >So, make no mistake, whether we end up as a WG or a BoF between now and >Quebec, "we're back" - please send comments, and make your travel or >remote-attendance plans accordingly if you want to participate. > >Jari has asked me to co-chair the session in Quebec. As such, I'd like to >take requests for presentation time now. Jari and I will likely begin the >session with a scoping overview, as well as a first cut at an >architecture framework, but there should be some time for a few other >items. When submitting your request, please identify which of the 5 areas >below you think your work applies to as well as the internet-draft, of >course. > >Thanks, and see you on the list and in Quebec. > >- Mark > > >On Jun 29, 2011, at 10:35 AM, Jari Arkko wrote: > >> I wanted to provide an update of the situation with this working group >>proposal. >> >> HOMENET is a new working group proposal, a variation of the >>HOMEGATE/HOMENET theme that we discussed last year, but this time >>looking at it from a different angle. The old effort was mostly focused >>about what home gateways should do: forwarding, transport, and DNS >>proxying issues. The new effort is about home networks themselves, in >>particular what kind of network architecture and configuration is >>necessary to support IPv6-based home networks. We view IPv4-based home >>networks as "done" at this time (or perhaps as "cannot be changed >>anyway"). >> >> I have been discussing this effort in the background for the last >>couple of month with Mark Townsley and others, and more publicly since >>early June. The proposal has been brought to the IESG, IAB and some >>directorates for discussion, and we've been going back and forth whether >>this is ready to become a working group or needs to be run as a BOF in >>Quebec City. The current plan is that the working group proposal goes to >>IETF-wide review this week, and if the feedback from the community, IAB, >>and the IESG is positive, we will create the working group just in time >>for the IETF. Otherwise, the slot reserved in the agenda for the meeting >>will be used to run the proposal as a BOF. >> >> In any case, I would like to solicit discussion on this topic, and >>perhaps some early drafts as well. Please comment on the charter at >>least. >> >> Note that the new proposal was called FUN at the time that we created >>the list. It has now been renamed back to HOMENET to be more >>descriptive. The list will be renamed soon as well (current subscribers >>will stay). >> >> This is the most recent version of the charter we should discuss: >> >> Home Networks (homenet) >> ----------------------------------- >> >> Current Status: Proposed >> Last Edit: Wednesday, June 29th, 2011 >> >> Chairs: >> TBD >> >> Internet Area Directors: >> Ralph Droms >> Jari Arkko >> >> Internet Area Advisor: >> Jari Arkko >> >> Routing Area Technical Advisor: >> TBD >> >> Security Area Technical Advisor: >> TBD >> >> Mailing Lists: >> General Discussion: fun@ietf.org >> To Subscribe: https://www.ietf.org/mailman/listinfo/fun >> Archive: http://www.ietf.org/mail-archive/web/fun >> >> Description of Working Group: >> >> This working group focuses on the evolving networking technology >> within and among relatively small =B3residential home=B2 networks. For >> example, an obvious trend in home networking is the proliferation of >> networking technology in an increasingly broad range and number of >> devices. This evolution in scale and diversity sets some requirements >> on IETF protocols. Some of the relevant trends include: >> >> o Multiple segments: While less complex L3-toplogies involving as few >> subnets as possible are preferred in home networks for a variety of >> reasons including simpler management and service discovery, the >> introduction of more than one subnet into a home network is enough >> to add complexity that needs to be addressed, and multiple >> dedicated segments are necessary for some cases. For instance, a >> common feature in modern home routers in the ability to support >> both guest and private network segments. Also, link layer >> networking technology is poised to become more heterogeneous, as >> networks begin to employ both traditional Ethernet technology and >> link layers designed for low-powered sensor networks. Finally, >> similar needs for segmentation may occur in other cases, such as >> separating building control or corporate extensions from the >> Internet access network. Different segments may be associated with >> subnets that have different routing and security policies. >> >> o Service providers are deploying IPv6, and support for IPv6 is >> increasingly available in home gateway devices. While IPv6 resembles >> IPv4 in many ways, it changes address allocation principles and allows >> direct IP addressability and routing to devices in the home from the >> Internet. This is a promising area in IPv6 that has proved challenging >> in IPv4 with the proliferation of NAT. >> >> o End-to-end communication is both an opportunity and a concern as it >> enables new applications but also exposes nodes in the internal >> networks to receipt of unwanted traffic from the Internet. Firewalls >> that restrict incoming connections may be used to prevent exposure, >> however, this reduces the efficacy of end-to-end connectivity that >> IPv6 has the potential to restore. >> >> Home networks need to provide the tools to handle these situations in >> a manner accessible to all users of home networks. Manual >> configuration is rarely, if at all, possible. The purpose of this >> working group is to focus on this evolution, in particular as it >> addresses the introduction of IPv6, by developing an architecture >> addressing this full scope of requirements: >> >> o prefix configuration for routers >> o managing routing >> o name resolution >> o service discovery >> o network security >> >> The task of the group is to produce an architecture document that >> outlines how to construct home networks involving multiple routers and >> subnets. This document is expected to apply the IPv6 addressing >> architecture, prefix delegation, global and ULA addresses, source >> address selection rules and other existing components of the IPv6 >> architecture. The architecture document should drive what protocols >> changes, if any, are necessary. Specific protocol work described below >> is expected to be within the scope of the working group one the >> architecture work is complete. However, the group is required to >> review its charter and milestones with the IESG and IETF community >> before submitting documents that make protocol changes. It is expected >> that the group has to discuss some of the below solutions, however, in >> order to complete the architecture work. >> >> The group will apply existing protocols to handle the five >> requirements above. For prefix configuration, existing protocols are >> likely sufficient, and at worst may need some small enhancements, such >> as new options. For automatic routing, it is expected that existing >> routing protocols can be used as is, however, a new mechanism may be >> needed in order to turn a selected protocol on by default. For name >> resolution and service discovery, extensions to existing >> multicast-based name resolution protocols are needed to enable them to >> work across subnets. >> >> For network security, the group shall document the concept of >> "advanced security" as a further development of "simple security" from >> RFC 6092. The main goal of this work is to enable a security policy >> that adapts to IPv6 threats as they emerge, taking into account not >> only traffic from the Internet at large, but within and leaving the >> home network itself. >> >> It is expected that the working group will define a set of protocol >> specifications to accomplish the five requirements from >> above. However, it is not in the scope of the working group to define >> entirely new routing protocols or address allocation protocols. As >> noted, additional options or other small extensions may be necessary >> to use the existing protocols in these new configuration tasks. The >> working group shall also not make any changes to IPv6 protocols or >> addressing architecture. Prefix configuration, routing, and security >> related work shall not cause any changes that are not backwards >> compatible to existing IPv6 hosts. There may be host visible changes >> in the work on naming and discovery protocols, however. In its design, >> the working group shall also consider security aspects and the impact >> on manageability. The main focus of the working group is home >> networks, but the group's results may also find applications in other >> small networks. >> >> The working group will liaise with the relevant IETF working >> groups. In particular, the group should work closely with the V6OPS >> working group, review any use or extension of DHCP with the DHC >> working group, and work with additional DNS requirements with the >> DNSEXT and DNSOP working groups. If it turns out that additional >> options are needed for a routing protocol, they will be developed in >> the appropriate Routing Area working group, with the HOMENET working >> group providing the architecture and requirements for such >> enhancements. The working group will also liase with external >> standards bodies where it is expected that there are normative >> dependencies between the specifications of the two bodies. >> It is expected that in the architecture definition stage liaising >> with the Broadband Forum, DLNA, and UPnP Forum is necessary. >> >> Milestones: >> >> Jul 2011 Formation of the working group >> Sep 2011 First WG draft on the architecture >> Dec 2011 Submission of the architecture draft to the IESG as >>Informational RFC >> Dec 2011 Charter re-evaluation based on the architecture work >> Dec 2011 First WG draft on prefix configuration >> Dec 2011 First WG draft on routing >> Jan 2012 First WG draft on name resolution >> Feb 2012 First WG draft on service discovery >> Feb 2012 First WG draft on perimeter security >> Feb 2012 Start of routing related work in the relevant routing area >>working group, if needed >> Mar 2012 Submission of the prefix configuration draft to the IESG as >>Standards Track RFC >> Apr 2012 Submission of the routing draft to the IESG as Informational >>RFC >> Sep 2012 Submission of the name resolution draft to the IESG as >>Standards Track RFC >> Nov 2012 Submission of the service discovery draft to the IESG as >>Standards Track RFC >> Dec 2012 Submission of the perimeter security draft to the IESG as >>Informational RFC >> >> _______________________________________________ >> fun mailing list >> fun@ietf.org >> https://www.ietf.org/mailman/listinfo/fun > >_______________________________________________ >fun mailing list >fun@ietf.org >https://www.ietf.org/mailman/listinfo/fun 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 palm@broadcom.com Thu Jun 30 07:41:40 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B388B11E8091; Thu, 30 Jun 2011 07:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1DwscrhRJezS; Thu, 30 Jun 2011 07:41:39 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5964C22800E; Thu, 30 Jun 2011 07:41:39 -0700 (PDT) Received: from [10.9.200.131] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Thu, 30 Jun 2011 07:46:16 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from mail-irva-13.broadcom.com (10.11.16.103) by IRVEXCHHUB01.corp.ad.broadcom.com (10.9.200.131) with Microsoft SMTP Server id 8.2.247.2; Thu, 30 Jun 2011 07:41:22 -0700 Received: from [10.9.254.251] (unknown [10.9.254.251]) by mail-irva-13.broadcom.com (Postfix) with ESMTP id D982B74D04; Thu, 30 Jun 2011 07:41:21 -0700 (PDT) Message-ID: <4E0C8B11.3070609@broadcom.com> Date: Thu, 30 Jun 2011 07:41:21 -0700 From: "Stephen [kiwin] PALM" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: "Fernando Gont" References: <4E0AE696.4020603@piuha.net> <4E0BDCF3.1090003@gont.com.ar> <4E0C1CF8.7090601@gont.com.ar> In-Reply-To: <4E0C1CF8.7090601@gont.com.ar> X-WSS-ID: 621253B23B411813245-01-01 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF Discussion , fun@ietf.org, "homegate@ietf.org" Subject: Re: [fun] [homegate] HOMENET working group proposal X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 14:41:40 -0000 Agreed. I would phrase it this way: How to do IPv6 in an IPv4 world. Some points from the Description: > o Service providers are deploying IPv6, and support for IPv6 is > increasingly available in home gateway devices. This is only *part* of the story. *Users* have lots of IPv4 devices in their home. > o service discovery This is already well handled by UPnP/DLNA > o managing routing There were several snippets regarding routing/subnets/heterogeneous networking technologies. There is already work proceeding in IEEE P1905.1 to address issues related to multiple network technologies via a MAC/PHY Abstraction Layer. Also there are applications today that expect a single subnet, so new architectures should not preclude existing applications. regards, kiwin On 6/29/2011 11:51 PM, Fernando Gont wrote: > On 06/30/2011 02:12 AM, Mikael Abrahamsson wrote: >>> My high level comment/question is: the proposed charter seems to >>> stress that IPv6 is the driver behind this potential wg effort... >>> however, I think that this deserves more discussion -- it's not clear >>> to me why/how typical IPv6 home networks would be much different from >>> their IPv4 counterparts. >> >> In my mind, I see the possibility of /56 PD enabling different subnets >> for different kinds of devices with different security and functional >> needs, and also chaining of L3 devices. This definitely warrants a group >> to look at that. > > My point was that, except for the mechanism for PD, I don't see a > substantial difference here that would e.g. prevent this from being > developed for IPv4 (in addition to IPv6). -- Yes, I know we need to > deploy IPv6... but I don't think you can expect people to get rid of > their *working* IPv4 devices... (i.e., not sure why any of this > functionality should be v6-only) > > >>> One would hope/expect that the former will be gone with IPv6. However, >>> I don't think the latter will. As a result, even when you could >>> "address" nodes that belong to the "home network", you probably won't >>> be able to get your packets to them, unless those nodes initiated the >>> communication instance. >> >> This is exactly why the whole "system" needs to work, including uPNP >> like functionality for nodes to talk to the firewall(s). > > I think this deserves a problem statement that clearly describes what we > expect to be able to do (but currently can't), etc. And, if this is > meant to be v6-only, state why v4 is excluded -- unless we're happy to > have people connect their IPv4-devices, and see that they cannot > communicate anymore. > > Thanks, -- Stephen [kiwin] Palm Ph.D. E: palm@kiwin.com Senior Technical Director T: +1-949-926-PALM Broadcom Broadband Communications Group F: +1-949-926-7256 Irvine, California W: http://www.kiwin.com Secondary email accounts: stephenpalm@alumni.uci.edu palm@broadcom.com s.palm@ieee.org palm@itu.ch spalm@cs.cmu.edu palm@ics.t.u-tokyo.ac.jp From moore@network-heretics.com Thu Jun 30 05:22:04 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88EA321F86D1; Thu, 30 Jun 2011 05:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKpLJBXKoj-z; Thu, 30 Jun 2011 05:22:03 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id A57D321F865B; Thu, 30 Jun 2011 05:22:02 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id 5BA2820181; Thu, 30 Jun 2011 08:22:02 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Thu, 30 Jun 2011 08:22:02 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=ZbxK6nbRyA6gVw3Pu9B3x89x3ZQ=; b=XDADsYdVapmJGfAnUIeXptVhzXAwg59vuxoxncGmAPaRNnMirdAlgBONTps6QFJuBirOaZrJaEXIsVIpRcca0nenzkuMequ1zyictm5txo0xj2FKAKFAeaKJSR85EeaKEc/4QCIz1HfDpnjd3tYb2lmRdQ+KbTL2H/XR0G4l6nw= X-Sasl-enc: hAibfs0jglKJUk/ZIyoc0FnbVi9AbZxcGXsNVYF2KtJc 1309436521 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 26618402367; Thu, 30 Jun 2011 08:22:01 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <4E0C4631.3010409@gont.com.ar> Date: Thu, 30 Jun 2011 08:21:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <94830A23-F251-4EDC-8002-11422CF691E2@network-heretics.com> References: <4E0AE696.4020603@piuha.net> <4E0BDCF3.1090003@gont.com.ar> <4E0C1CF8.7090601@gont.com.ar> <4E0C4417.90804@piuha.net> <4E0C4631.3010409@gont.com.ar> To: Fernando Gont X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Thu, 30 Jun 2011 07:52:33 -0700 Cc: IETF Discussion , "fun@ietf.org" Subject: Re: [fun] [homegate] HOMENET working group proposal X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 12:22:04 -0000 On Jun 30, 2011, at 5:47 AM, Fernando Gont wrote: > Jari, >=20 > On 06/30/2011 06:38 AM, Jari Arkko wrote: >> But their architecture is largely done and cannot be easily affected. >> Vendors are now looking into adding IPv6 into their home routers and >> other devices. I want to be able to show them how to do it right. = They >> can, of course, replicate everything exactly as in IPv4. Much of it = is >> right, of course, but on some areas I think we can do better. This is >> why the working group should focus on IPv6.=20 >=20 > My point is: Will implementation of the produced RFCs lead to home > networks in which stuff works for IPv6 differently from how it works = for > IPv4? hopefully! > e.g., your home network would have multiple subnets (thanks to > PD), but a single IPv4 subnet? for that specific example, not clear. my impression is that the = architecture of home networks should work regardless of whether there's = a single subnet or multiple subnets. > If our work focuses only on IPv6, I get the impression that we're > heading in that direction. nothing says that some results of the work can't also apply to IPv4. = but people are far too mired in outdated assumptions today, such as the = idea that every network needs a NAT or a firewall that filters based on = IP addresses and ports. > If HOMENET is going to improve stuff that we already do with IPv4 (by > leveraging IPv6), then that's fine...=20 no, that's not fine. that's painting ourselves (and the Internet) into = a corner. Keith From palm@broadcom.com Thu Jun 30 07:56:27 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A55C322800E; Thu, 30 Jun 2011 07:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TRH1SOEuSv4l; Thu, 30 Jun 2011 07:56:26 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by ietfa.amsl.com (Postfix) with ESMTP id A543D22800D; Thu, 30 Jun 2011 07:56:26 -0700 (PDT) Received: from [10.9.200.131] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Thu, 30 Jun 2011 08:00:35 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from mail-irva-13.broadcom.com (10.11.16.103) by IRVEXCHHUB01.corp.ad.broadcom.com (10.9.200.131) with Microsoft SMTP Server id 8.2.247.2; Thu, 30 Jun 2011 07:55:40 -0700 Received: from [10.9.254.251] (unknown [10.9.254.251]) by mail-irva-13.broadcom.com (Postfix) with ESMTP id A19F174D04; Thu, 30 Jun 2011 07:55:40 -0700 (PDT) Message-ID: <4E0C8E6C.3020205@broadcom.com> Date: Thu, 30 Jun 2011 07:55:40 -0700 From: "Stephen [kiwin] PALM" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: "Mark Townsley" References: <4E0AE696.4020603@piuha.net> <4E0BDCF3.1090003@gont.com.ar> <4E0C1CF8.7090601@gont.com.ar> <558D0669-8B2A-4514-B3FB-C690C40A4EF8@townsley.net> In-Reply-To: <558D0669-8B2A-4514-B3FB-C690C40A4EF8@townsley.net> X-WSS-ID: 621250193B411821620-01-01 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "fun@ietf.org" , "homegate@ietf.org" , IETF Discussion Subject: Re: [fun] [homegate] HOMENET working group proposal X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 14:56:27 -0000 Thanks Mark for stating that. It would really be helpful if this type of text is included in the description/charter. The lack of of this information in the recently distributed material caused several immediate allergic reactions... regards, kiwin On 6/30/2011 2:57 AM, Mark Townsley wrote: > > I think the consensus we had in the past BoFs and discussion in and around this topic can be summed up as stating that homenet deliverables will: > > - coexist with (existing) IPv4 protocols, devices, applications, etc. > - operate in a (future) IPv6-only home network in the absence of IPv4 > - be IP-agnostic whenever possible > > In other words, anything we do for the IPv6 homenet cannot actively break what's already running on IPv4. Also, trying to define what the IPv4 home network should be has long reached a point of diminishing returns given the effort in doing so coupled with our ability to significantly affect what's already deployed. There's still hope we can help direct IPv6, as such that is homenet's primary focus. However, when we can define something that is needed for IPv6 in a way that is also useful for IPv4 without making significant concessions, we should go ahead and do so. > > - Mark > > > > On Jun 30, 2011, at 9:25 AM, Mikael Abrahamsson wrote: > >> On Thu, 30 Jun 2011, Fernando Gont wrote: >> >>> My point was that, except for the mechanism for PD, I don't see a substantial difference here that would e.g. prevent this from being developed for IPv4 (in addition to IPv6). -- Yes, I know we need to deploy IPv6... but I don't think you can expect people to get rid of their *working* IPv4 devices... (i.e., not sure why any of this functionality should be v6-only) >> >> Chaining NAT boxes already work. I also feel that we shouldn't put in a lot of work to develop IPv4 further, that focus should be put on IPv6. >> >>> I think this deserves a problem statement that clearly describes what we expect to be able to do (but currently can't), etc. And, if this is meant to be v6-only, state why v4 is excluded -- unless we're happy to have people connect their IPv4-devices, and see that they cannot communicate anymore. >> >> IPv4 should be excluded because it's a dead end, and we all know it. We're just disagreeing when it's going to die and how. >> >> -- >> Mikael Abrahamsson email: swmike@swm.pp.se >> _______________________________________________ >> homegate mailing list >> homegate@ietf.org >> https://www.ietf.org/mailman/listinfo/homegate > > _______________________________________________ > homegate mailing list > homegate@ietf.org > https://www.ietf.org/mailman/listinfo/homegate > -- Stephen [kiwin] Palm Ph.D. E: palm@kiwin.com Senior Technical Director T: +1-949-926-PALM Broadcom Broadband Communications Group F: +1-949-926-7256 Irvine, California W: http://www.kiwin.com Secondary email accounts: stephenpalm@alumni.uci.edu palm@broadcom.com s.palm@ieee.org palm@itu.ch spalm@cs.cmu.edu palm@ics.t.u-tokyo.ac.jp From ek@google.com Thu Jun 30 08:02:15 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 584FE11E80A2 for ; Thu, 30 Jun 2011 08:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6CNZSToFabIG for ; Thu, 30 Jun 2011 08:02:11 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE0911E8078 for ; Thu, 30 Jun 2011 08:02:11 -0700 (PDT) Received: from hpaq7.eem.corp.google.com (hpaq7.eem.corp.google.com [172.25.149.7]) by smtp-out.google.com with ESMTP id p5UF2A0D018388 for ; Thu, 30 Jun 2011 08:02:10 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1309446130; bh=RExe1DDgQkceelfgQ3zp/E4YQrE=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=M5CfkYl/BUHla11d9xMfdZWastBOD7lNDjXAqoD7ZK1DUhCNEguDzL7H12XuDLQtm Mbg3j7ZngDcCnODN+7QZg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=fAehPAR8NpoHarbAeIeNrBA64s3TCXVjhCbQBCfAiq9VU1aSR90Se5h1KUPb+f5Lr e1lTGC+d4YcUASkUunNbQ== Received: from pzk28 (pzk28.prod.google.com [10.243.19.156]) by hpaq7.eem.corp.google.com with ESMTP id p5UF1ldf015709 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 30 Jun 2011 08:02:08 -0700 Received: by pzk28 with SMTP id 28so2090160pzk.36 for ; Thu, 30 Jun 2011 08:02:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KkjF8YCiWoV9u08ptW08LaEf079r5xG6dE6FmOOKxfc=; b=VdAPjkjrFgiA2p51A+kwxYJ6zL7AaLpTf2l3Q3LYksc6xXF8fEPIamSh//qtzO7B5E jz5x7AVUr1UnCCXoiPkA== MIME-Version: 1.0 Received: by 10.142.121.15 with SMTP id t15mr1031657wfc.324.1309445755672; Thu, 30 Jun 2011 07:55:55 -0700 (PDT) Received: by 10.142.179.17 with HTTP; Thu, 30 Jun 2011 07:55:55 -0700 (PDT) In-Reply-To: References: <98D97264-A266-41FB-9913-A48A7105F73F@townsley.net> Date: Thu, 30 Jun 2011 23:55:55 +0900 Message-ID: From: Erik Kline To: "Weil, Jason" Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: "fun@ietf.org" , "homegate@ietf.org" Subject: Re: [fun] status of the homenet effort X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 15:02:15 -0000 > If we can stay focussed on solving just the basics for the five areas > included, I believe it will be helpful. The other recommendation would be > to work as expeditiously as possible. Providers in the process of > deploying IPv6 now are already deep into this analysis and development > with their vendors. If we wait too long then these topics will be solved > with interoperability a possible casualty. +1 to whatever can be done to get more industry implementors to IETF81 in a few weeks From jason.weil@twcable.com Thu Jun 30 08:06:21 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFD8011E8166; Thu, 30 Jun 2011 08:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.163 X-Spam-Level: X-Spam-Status: No, score=-0.163 tagged_above=-999 required=5 tests=[AWL=0.300, 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 jDn6cAje65Fk; Thu, 30 Jun 2011 08:06:21 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id B844A11E8165; Thu, 30 Jun 2011 08:06:20 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.65,450,1304308800"; d="scan'208";a="244401990" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 30 Jun 2011 11:05:13 -0400 Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.28]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Thu, 30 Jun 2011 11:06:20 -0400 From: "Weil, Jason" To: Mark Townsley , "homegate@ietf.org" , IETF Discussion , "fun@ietf.org" Date: Thu, 30 Jun 2011 11:06:18 -0400 Thread-Topic: [fun] [homegate] HOMENET working group proposal Thread-Index: Acw3N0QENp1awgw7QgCuxWlYWR/P2g== Message-ID: In-Reply-To: <558D0669-8B2A-4514-B3FB-C690C40A4EF8@townsley.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.0.0.100825 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [fun] [homegate] HOMENET working group proposal X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 15:06:21 -0000 Mark, 100% in agreement with this stance. Just to echo what Fernando has already stated, you can't completely ignore IPv4 in the home network especially when you are talking about a multi-segmented network. For example RFC6204 calls for a separate /64 on each LAN interface per the L-2 requirement. In IPv4 these interfaces nearly always operate in bridged mode. Supporting bridged IPv4 and routed IPv6 on the same physical interface could pose a challenge. Overall I like the concept of not breaking core IPv4 functionality while focussing all new functionality to IPv6. Jason On 6/30/11 5:57 AM, "Mark Townsley" wrote: > >I think the consensus we had in the past BoFs and discussion in and >around this topic can be summed up as stating that homenet deliverables >will: > >- coexist with (existing) IPv4 protocols, devices, applications, etc. >- operate in a (future) IPv6-only home network in the absence of IPv4 >- be IP-agnostic whenever possible > >In other words, anything we do for the IPv6 homenet cannot actively break >what's already running on IPv4. Also, trying to define what the IPv4 home >network should be has long reached a point of diminishing returns given >the effort in doing so coupled with our ability to significantly affect >what's already deployed. There's still hope we can help direct IPv6, as >such that is homenet's primary focus. However, when we can define >something that is needed for IPv6 in a way that is also useful for IPv4 >without making significant concessions, we should go ahead and do so. > >- Mark > > > >On Jun 30, 2011, at 9:25 AM, Mikael Abrahamsson wrote: > >> On Thu, 30 Jun 2011, Fernando Gont wrote: >> >>> My point was that, except for the mechanism for PD, I don't see a >>>substantial difference here that would e.g. prevent this from being >>>developed for IPv4 (in addition to IPv6). -- Yes, I know we need to >>>deploy IPv6... but I don't think you can expect people to get rid of >>>their *working* IPv4 devices... (i.e., not sure why any of this >>>functionality should be v6-only) >> >> Chaining NAT boxes already work. I also feel that we shouldn't put in a >>lot of work to develop IPv4 further, that focus should be put on IPv6. >> >>> I think this deserves a problem statement that clearly describes what >>>we expect to be able to do (but currently can't), etc. And, if this is >>>meant to be v6-only, state why v4 is excluded -- unless we're happy to >>>have people connect their IPv4-devices, and see that they cannot >>>communicate anymore. >> >> IPv4 should be excluded because it's a dead end, and we all know it. >>We're just disagreeing when it's going to die and how. >> >> -- >> Mikael Abrahamsson email: swmike@swm.pp.se >> _______________________________________________ >> homegate mailing list >> homegate@ietf.org >> https://www.ietf.org/mailman/listinfo/homegate > >_______________________________________________ >fun mailing list >fun@ietf.org >https://www.ietf.org/mailman/listinfo/fun 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 palm@broadcom.com Thu Jun 30 08:10:34 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03A6E11E818C; Thu, 30 Jun 2011 08:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5aEPfsfx2Wo; Thu, 30 Jun 2011 08:10:32 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by ietfa.amsl.com (Postfix) with ESMTP id 73DE411E8185; Thu, 30 Jun 2011 08:10:08 -0700 (PDT) Received: from [10.9.200.131] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Thu, 30 Jun 2011 08:14:46 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from mail-irva-13.broadcom.com (10.11.16.103) by IRVEXCHHUB01.corp.ad.broadcom.com (10.9.200.131) with Microsoft SMTP Server id 8.2.247.2; Thu, 30 Jun 2011 08:09:51 -0700 Received: from [10.9.254.251] (unknown [10.9.254.251]) by mail-irva-13.broadcom.com (Postfix) with ESMTP id 3AF2B74D04; Thu, 30 Jun 2011 08:09:51 -0700 (PDT) Message-ID: <4E0C91BE.6050807@broadcom.com> Date: Thu, 30 Jun 2011 08:09:50 -0700 From: "Stephen [kiwin] PALM" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: "Weil, Jason" References: In-Reply-To: X-WSS-ID: 62124D6C3B411829987-01-01 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "fun@ietf.org" , "homegate@ietf.org" , IETF Discussion Subject: Re: [fun] [homegate] HOMENET working group proposal X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 15:10:34 -0000 On 6/30/2011 8:06 AM, Weil, Jason wrote: > Overall I like the concept of not breaking core IPv4 functionality while > focussing all new functionality to IPv6. It is more than just IPv4 functionality... it is all the deployed applications and devices that utilize IPv4.... and for whatever reason, cannot be "upgraded" to IPv6. 8-) regards, kiwin > On 6/30/11 5:57 AM, "Mark Townsley" wrote: > >> >> I think the consensus we had in the past BoFs and discussion in and >> around this topic can be summed up as stating that homenet deliverables >> will: >> >> - coexist with (existing) IPv4 protocols, devices, applications, etc. >> - operate in a (future) IPv6-only home network in the absence of IPv4 >> - be IP-agnostic whenever possible >> >> In other words, anything we do for the IPv6 homenet cannot actively break >> what's already running on IPv4. Also, trying to define what the IPv4 home >> network should be has long reached a point of diminishing returns given >> the effort in doing so coupled with our ability to significantly affect >> what's already deployed. There's still hope we can help direct IPv6, as >> such that is homenet's primary focus. However, when we can define >> something that is needed for IPv6 in a way that is also useful for IPv4 >> without making significant concessions, we should go ahead and do so. >> >> - Mark >> >> >> >> On Jun 30, 2011, at 9:25 AM, Mikael Abrahamsson wrote: >> >>> On Thu, 30 Jun 2011, Fernando Gont wrote: >>> >>>> My point was that, except for the mechanism for PD, I don't see a >>>> substantial difference here that would e.g. prevent this from being >>>> developed for IPv4 (in addition to IPv6). -- Yes, I know we need to >>>> deploy IPv6... but I don't think you can expect people to get rid of >>>> their *working* IPv4 devices... (i.e., not sure why any of this >>>> functionality should be v6-only) >>> >>> Chaining NAT boxes already work. I also feel that we shouldn't put in a >>> lot of work to develop IPv4 further, that focus should be put on IPv6. >>> >>>> I think this deserves a problem statement that clearly describes what >>>> we expect to be able to do (but currently can't), etc. And, if this is >>>> meant to be v6-only, state why v4 is excluded -- unless we're happy to >>>> have people connect their IPv4-devices, and see that they cannot >>>> communicate anymore. >>> >>> IPv4 should be excluded because it's a dead end, and we all know it. >>> We're just disagreeing when it's going to die and how. >>> >>> -- >>> Mikael Abrahamsson email: swmike@swm.pp.se >>> _______________________________________________ >>> homegate mailing list >>> homegate@ietf.org >>> https://www.ietf.org/mailman/listinfo/homegate >> >> _______________________________________________ >> fun mailing list >> fun@ietf.org >> https://www.ietf.org/mailman/listinfo/fun > > > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. > _______________________________________________ > fun mailing list > fun@ietf.org > https://www.ietf.org/mailman/listinfo/fun > -- Stephen [kiwin] Palm Ph.D. E: palm@kiwin.com Senior Technical Director T: +1-949-926-PALM Broadcom Broadband Communications Group F: +1-949-926-7256 Irvine, California W: http://www.kiwin.com Secondary email accounts: stephenpalm@alumni.uci.edu palm@broadcom.com s.palm@ieee.org palm@itu.ch spalm@cs.cmu.edu palm@ics.t.u-tokyo.ac.jp From mark@townsley.net Thu Jun 30 08:14:06 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A91BF11E818C; Thu, 30 Jun 2011 08:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2MeOSs9cQ5Q; Thu, 30 Jun 2011 08:14:04 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7C7F011E8189; Thu, 30 Jun 2011 08:14:03 -0700 (PDT) Received: by wyj26 with SMTP id 26so1856711wyj.31 for ; Thu, 30 Jun 2011 08:14:02 -0700 (PDT) Received: by 10.216.69.77 with SMTP id m55mr1905462wed.11.1309446842569; Thu, 30 Jun 2011 08:14:02 -0700 (PDT) Received: from ams-townsley-8714.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id k84sm1187097weq.46.2011.06.30.08.14.00 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 30 Jun 2011 08:14:01 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: <4E0C8E6C.3020205@broadcom.com> Date: Thu, 30 Jun 2011 17:13:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <518785F9-1FB4-456F-B4B4-26A97F9BC2F1@townsley.net> References: <4E0AE696.4020603@piuha.net> <4E0BDCF3.1090003@gont.com.ar> <4E0C1CF8.7090601@gont.com.ar> <558D0669-8B2A-4514-B3FB-C690C40A4EF8@townsley.net> <4E0C8E6C.3020205@broadcom.com> To: "Stephen [kiwin] PALM" X-Mailer: Apple Mail (2.1084) Cc: IETF Discussion , "fun@ietf.org" , "homegate@ietf.org" Subject: Re: [fun] [homegate] HOMENET working group proposal X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 15:14:06 -0000 On Jun 30, 2011, at 4:55 PM, Stephen [kiwin] PALM wrote: > Thanks Mark for stating that. > It would really be helpful if this type of text is included in the = description/charter. > The lack of of this information in the recently distributed material = caused > several immediate allergic reactions... I'm happy to include it in the next rev. - Mark >=20 > regards, kiwin >=20 > On 6/30/2011 2:57 AM, Mark Townsley wrote: >>=20 >> I think the consensus we had in the past BoFs and discussion in and = around this topic can be summed up as stating that homenet deliverables = will: >>=20 >> - coexist with (existing) IPv4 protocols, devices, applications, etc. >> - operate in a (future) IPv6-only home network in the absence of IPv4 >> - be IP-agnostic whenever possible >>=20 >> In other words, anything we do for the IPv6 homenet cannot actively = break what's already running on IPv4. Also, trying to define what the = IPv4 home network should be has long reached a point of diminishing = returns given the effort in doing so coupled with our ability to = significantly affect what's already deployed. There's still hope we can = help direct IPv6, as such that is homenet's primary focus. However, = when we can define something that is needed for IPv6 in a way that is = also useful for IPv4 without making significant concessions, we should = go ahead and do so. >>=20 >> - Mark >>=20 >>=20 >>=20 >> On Jun 30, 2011, at 9:25 AM, Mikael Abrahamsson wrote: >>=20 >>> On Thu, 30 Jun 2011, Fernando Gont wrote: >>>=20 >>>> My point was that, except for the mechanism for PD, I don't see a = substantial difference here that would e.g. prevent this from being = developed for IPv4 (in addition to IPv6). -- Yes, I know we need to = deploy IPv6... but I don't think you can expect people to get rid of = their *working* IPv4 devices... (i.e., not sure why any of this = functionality should be v6-only) >>>=20 >>> Chaining NAT boxes already work. I also feel that we shouldn't put = in a lot of work to develop IPv4 further, that focus should be put on = IPv6. >>>=20 >>>> I think this deserves a problem statement that clearly describes = what we expect to be able to do (but currently can't), etc. And, if this = is meant to be v6-only, state why v4 is excluded -- unless we're happy = to have people connect their IPv4-devices, and see that they cannot = communicate anymore. >>>=20 >>> IPv4 should be excluded because it's a dead end, and we all know it. = We're just disagreeing when it's going to die and how. >>>=20 >>> -- >>> Mikael Abrahamsson email: swmike@swm.pp.se >>> _______________________________________________ >>> homegate mailing list >>> homegate@ietf.org >>> https://www.ietf.org/mailman/listinfo/homegate >>=20 >> _______________________________________________ >> homegate mailing list >> homegate@ietf.org >> https://www.ietf.org/mailman/listinfo/homegate >>=20 >=20 > --=20 > Stephen [kiwin] Palm Ph.D. E: = palm@kiwin.com > Senior Technical Director T: = +1-949-926-PALM > Broadcom Broadband Communications Group F: = +1-949-926-7256 > Irvine, California W: = http://www.kiwin.com > Secondary email accounts: stephenpalm@alumni.uci.edu = palm@broadcom.com > s.palm@ieee.org palm@itu.ch spalm@cs.cmu.edu = palm@ics.t.u-tokyo.ac.jp >=20 > _______________________________________________ > homegate mailing list > homegate@ietf.org > https://www.ietf.org/mailman/listinfo/homegate From moore@network-heretics.com Thu Jun 30 08:46:50 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F45C11E8177; Thu, 30 Jun 2011 08:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLLNMY-h24aN; Thu, 30 Jun 2011 08:46:49 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id AFEB211E8181; Thu, 30 Jun 2011 08:46:49 -0700 (PDT) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.messagingengine.com (Postfix) with ESMTP id 50A9020941; Thu, 30 Jun 2011 11:46:49 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute4.internal (MEProxy); Thu, 30 Jun 2011 11:46:49 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=+8MO4cKZL1+XzoKUx/GM7OkLYEA=; b=ugUmrrMIg9UoVAXKG+QeaSDsGmfyKNYczHldeMrL6XhliNQ5nLuV1htPi5a/XssmQJ2PubGuPSaIlGtzPGiLF+Wwzxlet94qz10WHIkgW5MXV6kdINuchSGn/w+cvYJ5SCiqMvdsccw/v6/7Nsb4LBVGOrVRLwvf7oFOdcCG0AY= X-Sasl-enc: UXiQAhwqbCvOK/+zWoOs9kiiTeDIgy8y/n3DbtmuTcLN 1309448808 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 6E82140829D; Thu, 30 Jun 2011 11:46:48 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <558D0669-8B2A-4514-B3FB-C690C40A4EF8@townsley.net> Date: Thu, 30 Jun 2011 11:46:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0F995E91-9853-4018-91F0-0699E1A7A06F@network-heretics.com> References: <4E0AE696.4020603@piuha.net> <4E0BDCF3.1090003@gont.com.ar> <4E0C1CF8.7090601@gont.com.ar> <558D0669-8B2A-4514-B3FB-C690C40A4EF8@townsley.net> To: Mark Townsley X-Mailer: Apple Mail (2.1084) Cc: fun@ietf.org, homegate@ietf.org, IETF Discussion Subject: Re: [fun] [homegate] HOMENET working group proposal X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 15:46:50 -0000 On Jun 30, 2011, at 5:57 AM, Mark Townsley wrote: >=20 > I think the consensus we had in the past BoFs and discussion in and = around this topic can be summed up as stating that homenet deliverables = will: >=20 > - coexist with (existing) IPv4 protocols, devices, applications, etc. > - operate in a (future) IPv6-only home network in the absence of IPv4 > - be IP-agnostic whenever possible I'd like for this group to relax the "wherever possible" bit, so as to = not preclude solutions where IPv6 can do a better job than IPv4. IPv4 is a dinosaur gasping for its last breaths. Keith From fernando.gont.netbook.win@gmail.com Thu Jun 30 08:59:26 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF12D11E8188; Thu, 30 Jun 2011 08:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.447 X-Spam-Level: X-Spam-Status: No, score=-3.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQgsYRWH+3a0; Thu, 30 Jun 2011 08:59:26 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3959011E807E; Thu, 30 Jun 2011 08:59:26 -0700 (PDT) Received: by yie30 with SMTP id 30so1193451yie.31 for ; Thu, 30 Jun 2011 08:59:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=YOO3Wuijr9NTfgIPEUoKX6tKNH9WXm6nIFmX6b2ENPY=; b=NInN7EMNRhlt3Rf5rcqSHrWptf36C+2p1Ca39Y470ixkc8Jx8M3sGD86a/JjU/XEn0 uuMF+DLPHSiMQ/sHpD4aLqodYcQpTNbqc5VCKfN10D0dF/+Lw4oCUSbDxZDg8zgVP9Xd x8UevZOThQqUGj36hxKuhPzdEEjmTtEbV92Qs= Received: by 10.101.202.7 with SMTP id e7mr1923410anq.88.1309449565636; Thu, 30 Jun 2011 08:59:25 -0700 (PDT) Received: from [192.168.123.103] ([190.48.255.131]) by mx.google.com with ESMTPS id c19sm2093868anm.15.2011.06.30.08.59.22 (version=SSLv3 cipher=OTHER); Thu, 30 Jun 2011 08:59:24 -0700 (PDT) Sender: Fernando Gont Message-ID: <4E0C9D58.30002@gont.com.ar> Date: Thu, 30 Jun 2011 12:59:20 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: Keith Moore References: <4E0AE696.4020603@piuha.net> <4E0BDCF3.1090003@gont.com.ar> <4E0C1CF8.7090601@gont.com.ar> <558D0669-8B2A-4514-B3FB-C690C40A4EF8@townsley.net> <0F995E91-9853-4018-91F0-0699E1A7A06F@network-heretics.com> In-Reply-To: <0F995E91-9853-4018-91F0-0699E1A7A06F@network-heretics.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF Discussion , fun@ietf.org, homegate@ietf.org Subject: Re: [fun] [homegate] HOMENET working group proposal X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 15:59:27 -0000 On 06/30/2011 12:46 PM, Keith Moore wrote: > I'd like for this group to relax the "wherever possible" bit, so as to not preclude solutions where IPv6 can do a better job than IPv4. > > IPv4 is a dinosaur gasping for its last breaths. Just curious: when you expect IPv4 to be gone? (including "gone" from home and enterprise networks) Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From moore@network-heretics.com Thu Jun 30 09:05:46 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B34311E81C2; Thu, 30 Jun 2011 09:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDfl0bUwbLtv; Thu, 30 Jun 2011 09:05:45 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 6C94C11E8081; Thu, 30 Jun 2011 09:05:45 -0700 (PDT) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.messagingengine.com (Postfix) with ESMTP id 1E1DF20C58; Thu, 30 Jun 2011 12:05:45 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Thu, 30 Jun 2011 12:05:45 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=PLp8jPGs7cs5EmdUYPKcAQjl09Q=; b=MNUxzU7kN8q6IksZtStRL71GVwJPSlTuoMAJ9oWPttHFGUtuSV740///+kyOQdHnULCcZddiinwSSeXWOBWKMhQqyVDFAw+a2BghFSw0ujm0UJ20BiPC1KRzAPGRo9TgbgcGxBjE61KDekDglAUd/lsGGBg20kIcaULTVBHTLz4= X-Sasl-enc: +uAHtUdj3Hecqrj0fdhwwlPHbLKo5rTPiCZGBuCiSm+i 1309449944 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id F21B540923A; Thu, 30 Jun 2011 12:05:43 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <4E0C9D58.30002@gont.com.ar> Date: Thu, 30 Jun 2011 12:05:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E0AE696.4020603@piuha.net> <4E0BDCF3.1090003@gont.com.ar> <4E0C1CF8.7090601@gont.com.ar> <558D0669-8B2A-4514-B3FB-C690C40A4EF8@townsley.net> <0F995E91-9853-4018-91F0-0699E1A7A06F@network-heretics.com> <4E0C9D58.30002@gont.com.ar> To: Fernando Gont X-Mailer: Apple Mail (2.1084) Cc: IETF Discussion , fun@ietf.org, homegate@ietf.org Subject: Re: [fun] [homegate] HOMENET working group proposal X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 16:05:46 -0000 On Jun 30, 2011, at 11:59 AM, Fernando Gont wrote: > On 06/30/2011 12:46 PM, Keith Moore wrote: >> I'd like for this group to relax the "wherever possible" bit, so as = to not preclude solutions where IPv6 can do a better job than IPv4. >>=20 >> IPv4 is a dinosaur gasping for its last breaths. >=20 > Just curious: when you expect IPv4 to be gone? (including "gone" from > home and enterprise networks) I think it will be used for email and the web for at least ten years. I think there will be a need to talk to legacy IPv4-only devices for = about that long, perhaps a bit longer. But IPv4 is already difficult to use for a great many applications, and = it will only get worse with the imposition of LSN. A home network that = only supports IPv4, or which makes IPv6 as crippled as IPv4, is not a = desirable goal. Keith From rdroms@cisco.com Thu Jun 30 09:10:52 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9954511E8220; Thu, 30 Jun 2011 09:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.867 X-Spam-Level: X-Spam-Status: No, score=-8.867 tagged_above=-999 required=5 tests=[AWL=-1.732, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] 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 rZ+yNzpOEVLA; Thu, 30 Jun 2011 09:10:48 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 2F17E11E821A; Thu, 30 Jun 2011 09:10:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rdroms@cisco.com; l=941; q=dns/txt; s=iport; t=1309450248; x=1310659848; h=subject:references:content-transfer-encoding:from: in-reply-to:message-id:date:to:cc:mime-version; bh=bMk/E1TDsXlPxJTkXcj6b8wz2UZNv0T/jdC8hjpXTns=; b=lGSFZf0ZySMxw5azPr4ZInL6j5rbfrCASHU8wQJUa79ImDLVdMxDBlt9 +uDhGliKYOT/54S//c/BgmIVByQyvNt/W4Bs1hA7b5x60FKLf3lu0j16R 7Pf+57YN9odm+TaEZo4rfeyS8PtU8G+wybCBRFtK+1kkw2cW4nrhxrORF c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlkGAMyeDE6tJXG9/2dsb2JhbABSpmtpAneIeKFzngGGMQSSL4R/hzuEEA X-IronPort-AV: E=Sophos;i="4.65,450,1304294400"; d="scan'208";a="724860735" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by sj-iport-6.cisco.com with ESMTP; 30 Jun 2011 16:10:47 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5UGAljP016732; Thu, 30 Jun 2011 16:10:47 GMT Received: from xmb-rcd-202.cisco.com ([72.163.62.209]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 30 Jun 2011 11:10:46 -0500 Received: from 144.254.231.94 ([144.254.231.94]) by XMB-RCD-202.cisco.com ([72.163.62.209]) with Microsoft Exchange Server HTTP-DAV ; Thu, 30 Jun 2011 16:10:47 +0000 References: <4E0AE696.4020603@piuha.net> <4E0BDCF3.1090003@gont.com.ar> <4E0C1CF8.7090601@gont.com.ar> <558D0669-8B2A-4514-B3FB-C690C40A4EF8@townsley.net> <0F995E91-9853-4018-91F0-0699E1A7A06F@network-heretics.com> <4E0C9D58.30002@gont.com.ar> Content-Transfer-Encoding: quoted-printable thread-topic: [fun] [homegate] HOMENET working group proposal thread-index: Acw3QEVSasHua7EIRTmly+ZH07zAOQ== From: "Ralph Droms (rdroms)" Content-Type: text/plain; charset="us-ascii" In-Reply-To: <4E0C9D58.30002@gont.com.ar> Message-ID: Date: Thu, 30 Jun 2011 12:11:31 -0400 To: "Fernando Gont" MIME-Version: 1.0 (iPad Mail 8J3) X-OriginalArrivalTime: 30 Jun 2011 16:10:46.0824 (UTC) FILETIME=[455FC280:01CC3740] Cc: fun@ietf.org, Keith Moore , IETF Discussion Subject: Re: [fun] [homegate] HOMENET working group proposal X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 16:10:52 -0000 "Gone" isn't so important as "not worth expending any more energy on.". So I= 'm with Keith and would like to find some words like "when it doesn't take a= ny more work." - Ralph On Jun 30, 2011, at 12:00 PM, "Fernando Gont" wrote: > On 06/30/2011 12:46 PM, Keith Moore wrote: >> I'd like for this group to relax the "wherever possible" bit, so as to no= t preclude solutions where IPv6 can do a better job than IPv4. >>=20 >> IPv4 is a dinosaur gasping for its last breaths. >=20 > Just curious: when you expect IPv4 to be gone? (including "gone" from > home and enterprise networks) >=20 > Thanks, > --=20 > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >=20 >=20 >=20 > _______________________________________________ > fun mailing list > fun@ietf.org > https://www.ietf.org/mailman/listinfo/fun From palm@broadcom.com Thu Jun 30 09:17:32 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E13D11E8229; Thu, 30 Jun 2011 09:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y8ZRQmqh1xnI; Thu, 30 Jun 2011 09:17:31 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by ietfa.amsl.com (Postfix) with ESMTP id A809811E8228; Thu, 30 Jun 2011 09:17:31 -0700 (PDT) Received: from [10.9.200.131] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Thu, 30 Jun 2011 09:21:59 -0700 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: from mail-irva-13.broadcom.com (10.11.16.103) by IRVEXCHHUB01.corp.ad.broadcom.com (10.9.200.131) with Microsoft SMTP Server id 8.2.247.2; Thu, 30 Jun 2011 09:17:23 -0700 Received: from [10.9.254.251] (unknown [10.9.254.251]) by mail-irva-13.broadcom.com (Postfix) with ESMTP id 933FA74D03; Thu, 30 Jun 2011 09:17:23 -0700 (PDT) Message-ID: <4E0CA192.1040801@broadcom.com> Date: Thu, 30 Jun 2011 09:17:22 -0700 From: "Stephen [kiwin] PALM" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: "Ralph Droms (rdroms)" References: <4E0AE696.4020603@piuha.net> <4E0BDCF3.1090003@gont.com.ar> <4E0C1CF8.7090601@gont.com.ar> <558D0669-8B2A-4514-B3FB-C690C40A4EF8@townsley.net> <0F995E91-9853-4018-91F0-0699E1A7A06F@network-heretics.com> <4E0C9D58.30002@gont.com.ar> In-Reply-To: X-WSS-ID: 62127D2D62O16854628-01-01 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Keith Moore , IETF Discussion , "fun@ietf.org" Subject: Re: [fun] [homegate] HOMENET working group proposal X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 16:17:32 -0000 It is not for "us" to decide when a user's network is not worth expending any more energy on. They have deployed their network... and do not want to expend any more energy themselves. If their SP deploys IPv6 inelegantly, the user would have a lot of frustration/work. Which will generate many expensive tech support calls... and potentially lost customers. It's not the protocols... it's the DEPLOYED APPLICATIONS and DEVICES that users have. regards, kiwin On 6/30/2011 9:11 AM, Ralph Droms (rdroms) wrote: > > "Gone" isn't so important as "not worth expending any more energy on.". So I'm with Keith and would like to find some words like "when it doesn't take any more work." > > - Ralph > > On Jun 30, 2011, at 12:00 PM, "Fernando Gont" wrote: > >> On 06/30/2011 12:46 PM, Keith Moore wrote: >>> I'd like for this group to relax the "wherever possible" bit, so as to not preclude solutions where IPv6 can do a better job than IPv4. >>> >>> IPv4 is a dinosaur gasping for its last breaths. >> >> Just curious: when you expect IPv4 to be gone? (including "gone" from >> home and enterprise networks) >> >> Thanks, >> -- >> Fernando Gont >> e-mail: fernando@gont.com.ar || fgont@acm.org >> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >> >> >> >> _______________________________________________ >> fun mailing list >> fun@ietf.org >> https://www.ietf.org/mailman/listinfo/fun > _______________________________________________ > fun mailing list > fun@ietf.org > https://www.ietf.org/mailman/listinfo/fun > -- Stephen [kiwin] Palm Ph.D. E: palm@kiwin.com Senior Technical Director T: +1-949-926-PALM Broadcom Broadband Communications Group F: +1-949-926-7256 Irvine, California W: http://www.kiwin.com Secondary email accounts: stephenpalm@alumni.uci.edu palm@broadcom.com s.palm@ieee.org palm@itu.ch spalm@cs.cmu.edu palm@ics.t.u-tokyo.ac.jp From rdroms@cisco.com Thu Jun 30 09:21:16 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42DD011E8239; Thu, 30 Jun 2011 09:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.002 X-Spam-Level: X-Spam-Status: No, score=-8.002 tagged_above=-999 required=5 tests=[AWL=-0.866, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] 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 9PTIlDJWfBmo; Thu, 30 Jun 2011 09:21:15 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9DD11E80D4; Thu, 30 Jun 2011 09:21:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rdroms@cisco.com; l=2480; q=dns/txt; s=iport; t=1309450875; x=1310660475; h=subject:references:content-transfer-encoding:from: in-reply-to:message-id:date:to:cc:mime-version; bh=/YzFBoYDbdtyVhNXYbVadblZkB8sZSySOSL6BylsKg0=; b=mn0C6V3+tx5dnzcm6e8f5rMTh8Bm1uWpKQE0S2YJnhvMWtKeKc3+HtmM aIQVLjIWdmm48dJRaURgtn35BmkaRbuoS9zOlExHd+mF9htbP+tgXRHfM XG530ltTATh0MxeijkV3t+JL8cLvGyE9zER7JqikXNuP8FNwUjYnvEGlo E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlsGAEaiDE6tJV2a/2dsb2JhbABMBqZraQJ3iHihVJ1+gzmCeASSL4R/hzuEEA X-IronPort-AV: E=Sophos;i="4.65,451,1304294400"; d="scan'208";a="389366045" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by sj-iport-2.cisco.com with ESMTP; 30 Jun 2011 16:20:55 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5UGKtjw016359; Thu, 30 Jun 2011 16:20:55 GMT Received: from xmb-rcd-202.cisco.com ([72.163.62.209]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 30 Jun 2011 11:20:54 -0500 Received: from 144.254.231.94 ([144.254.231.94]) by XMB-RCD-202.cisco.com ([72.163.62.209]) with Microsoft Exchange Server HTTP-DAV ; Thu, 30 Jun 2011 16:20:55 +0000 References: <4E0AE696.4020603@piuha.net> <4E0BDCF3.1090003@gont.com.ar> <4E0C1CF8.7090601@gont.com.ar> <558D0669-8B2A-4514-B3FB-C690C40A4EF8@townsley.net> <0F995E91-9853-4018-91F0-0699E1A7A06F@network-heretics.com> <4E0C9D58.30002@gont.com.ar> <4E0CA192.1040801@broadcom.com> Content-Transfer-Encoding: quoted-printable thread-topic: [fun] [homegate] HOMENET working group proposal thread-index: Acw3Qa+fE64S74PiSiOlBT71kq/XFw== From: "Ralph Droms (rdroms)" Content-Type: text/plain; charset="us-ascii" In-Reply-To: <4E0CA192.1040801@broadcom.com> Message-ID: <5289C05E-1105-4427-8459-D86E582BD23C@cisco.com> Date: Thu, 30 Jun 2011 12:21:37 -0400 To: "Stephen [kiwin] PALM" MIME-Version: 1.0 (iPad Mail 8J3) X-OriginalArrivalTime: 30 Jun 2011 16:20:54.0718 (UTC) FILETIME=[AFB505E0:01CC3741] Cc: Keith Moore , IETF Discussion , fun@ietf.org Subject: Re: [fun] [homegate] HOMENET working group proposal X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 16:21:16 -0000 On Jun 30, 2011, at 12:17 PM, "Stephen [kiwin] PALM" wro= te: > It is not for "us" to decide when a user's network is not worth expending > any more energy on. They have deployed their network... > and do not want to expend any more energy themselves. If their SP deploys= > IPv6 inelegantly, the user would have a lot of frustration/work. Which > will generate many expensive tech support calls... and potentially lost cu= stomers. Agreed that we need to avoid any disruptions of existing networks, devices a= nd deployment scenarios. I think we should avoid expending energy on *new* f= unctions for IPv4. - Ralph >=20 > It's not the protocols... it's the DEPLOYED APPLICATIONS and DEVICES that u= sers have. >=20 > regards, kiwin >=20 > On 6/30/2011 9:11 AM, Ralph Droms (rdroms) wrote: >>=20 >> "Gone" isn't so important as "not worth expending any more energy on.". S= o I'm with Keith and would like to find some words like "when it doesn't tak= e any more work." >>=20 >> - Ralph >>=20 >> On Jun 30, 2011, at 12:00 PM, "Fernando Gont" wrot= e: >>=20 >>> On 06/30/2011 12:46 PM, Keith Moore wrote: >>>> I'd like for this group to relax the "wherever possible" bit, so as to n= ot preclude solutions where IPv6 can do a better job than IPv4. >>>>=20 >>>> IPv4 is a dinosaur gasping for its last breaths. >>>=20 >>> Just curious: when you expect IPv4 to be gone? (including "gone" from >>> home and enterprise networks) >>>=20 >>> Thanks, >>> -- >>> Fernando Gont >>> e-mail: fernando@gont.com.ar || fgont@acm.org >>> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> fun mailing list >>> fun@ietf.org >>> https://www.ietf.org/mailman/listinfo/fun >> _______________________________________________ >> fun mailing list >> fun@ietf.org >> https://www.ietf.org/mailman/listinfo/fun >>=20 >=20 > --=20 > Stephen [kiwin] Palm Ph.D. E: palm@kiwin.com > Senior Technical Director T: +1-949-926-PALM > Broadcom Broadband Communications Group F: +1-949-926-7256 > Irvine, California W: http://www.kiwin.com > Secondary email accounts: stephenpalm@alumni.uci.edu palm@broadcom.com > s.palm@ieee.org palm@itu.ch spalm@cs.cmu.edu palm@ics.t.u-tokyo.ac.jp >=20 From mark@townsley.net Thu Jun 30 09:34:16 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B14E11E8244; Thu, 30 Jun 2011 09:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j72G+ipxciEH; Thu, 30 Jun 2011 09:34:15 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1E85711E8085; Thu, 30 Jun 2011 09:34:14 -0700 (PDT) Received: by wyj26 with SMTP id 26so1915743wyj.31 for ; Thu, 30 Jun 2011 09:34:14 -0700 (PDT) Received: by 10.216.237.8 with SMTP id x8mr256345weq.37.1309451653969; Thu, 30 Jun 2011 09:34:13 -0700 (PDT) Received: from ams-townsley-8714.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id d7sm1227232wek.21.2011.06.30.09.34.11 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 30 Jun 2011 09:34:12 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: <0F995E91-9853-4018-91F0-0699E1A7A06F@network-heretics.com> Date: Thu, 30 Jun 2011 18:33:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <780C3063-AD82-46F3-874A-C4E1E61EE508@townsley.net> References: <4E0AE696.4020603@piuha.net> <4E0BDCF3.1090003@gont.com.ar> <4E0C1CF8.7090601@gont.com.ar> <558D0669-8B2A-4514-B3FB-C690C40A4EF8@townsley.net> <0F995E91-9853-4018-91F0-0699E1A7A06F@network-heretics.com> To: Keith Moore X-Mailer: Apple Mail (2.1084) Cc: IETF Discussion , fun@ietf.org, homegate@ietf.org Subject: Re: [fun] [homegate] HOMENET working group proposal X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 16:34:16 -0000 On Jun 30, 2011, at 5:46 PM, Keith Moore wrote: >=20 > On Jun 30, 2011, at 5:57 AM, Mark Townsley wrote: >=20 >>=20 >> I think the consensus we had in the past BoFs and discussion in and = around this topic can be summed up as stating that homenet deliverables = will: >>=20 >> - coexist with (existing) IPv4 protocols, devices, applications, etc. >> - operate in a (future) IPv6-only home network in the absence of IPv4 >> - be IP-agnostic whenever possible >=20 > I'd like for this group to relax the "wherever possible" bit, so as to = not preclude solutions where IPv6 can do a better job than IPv4. Yes, and I think that IPv6 should naturally do a better job than IPv4 in = the cases where it can.=20 My original mail had this restatement of the above, which I think gets = closer to what you want: >> However, when we can define something that is needed for IPv6 in a = way that is also useful for IPv4 without making significant concessions, = we should go ahead and do so. - Mark >=20 > IPv4 is a dinosaur gasping for its last breaths. >=20 > Keith >=20 >=20 > _______________________________________________ > homegate mailing list > homegate@ietf.org > https://www.ietf.org/mailman/listinfo/homegate From mark@townsley.net Thu Jun 30 09:36:26 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22EF111E8247; Thu, 30 Jun 2011 09:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.224 X-Spam-Level: X-Spam-Status: No, score=-3.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5CIIrv85opt; Thu, 30 Jun 2011 09:36:24 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id C887911E8251; Thu, 30 Jun 2011 09:36:12 -0700 (PDT) Received: by wyj26 with SMTP id 26so1917122wyj.31 for ; Thu, 30 Jun 2011 09:36:12 -0700 (PDT) Received: by 10.216.234.80 with SMTP id r58mr1906876weq.109.1309451771819; Thu, 30 Jun 2011 09:36:11 -0700 (PDT) Received: from ams-townsley-8714.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id m46sm59438weq.15.2011.06.30.09.36.08 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 30 Jun 2011 09:36:09 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Mark Townsley In-Reply-To: Date: Thu, 30 Jun 2011 18:36:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7D900BF0-EA18-4ADA-A447-A9D3A717B61C@townsley.net> References: To: "Weil, Jason" X-Mailer: Apple Mail (2.1084) Cc: "fun@ietf.org" , "homegate@ietf.org" Subject: Re: [fun] status of the homenet effort X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 16:36:26 -0000 Thank you for the feedback, keep it coming. On Jun 30, 2011, at 4:14 PM, Weil, Jason wrote: > Mark, Raplh, Jari, et all, >=20 > I really appreciate the change in charter and direction for this = proposed > WG and the interest to keep it going. I believe it sets a path that is > scoped narrow enough to provide a workplace for achievable results. >=20 > As a provider working on writing, testing and implementing IPv6 CPE, I = can > relate firsthand that getting basic IPv6 functionality working in the = home > network is no simple feat and is still a work in progress. Don't get = me > wrong, basic functionality is there just not baked. What seems very > straightforward in theory typically fails in a multitude of corner = cases > ie reality. And just to clarify I am referring to a single /64 subnet > topology with no routing. >=20 > If we can stay focussed on solving just the basics for the five areas > included, I believe it will be helpful. The other recommendation would = be > to work as expeditiously as possible. Providers in the process of > deploying IPv6 now are already deep into this analysis and development > with their vendors. If we wait too long then these topics will be = solved > with interoperability a possible casualty. >=20 > FWIW, I would also add that the five topics in the charter are also = listed > in order > Of priority at least for me. >=20 >=20 > Thanks, >=20 > Jason >=20 >=20 > On 6/29/11 5:46 AM, "Mark Townsley" wrote: >=20 >>=20 >> All, >>=20 >> Apologies for double-posting if there are folks that are subscribed = to >> homegate@ietf.org and fun@ietf.org. I'm hoping soon that someone will >> finally create homenet@ietf.org and consolidate the membership >> accordingly. >>=20 >> In the charter proposal below, I think you will see a lot of = similarity >> with the consensus we achieved on the homegate list last year. Jari = has >> taken that, feedback from the IESG, IAB, members of the = IP-Directorate, >> v6ops chairs, etc. and shaped it towards something more focused on = the >> Internet (and Routing) area, as well as IPv6. I believe he and Ralph = both >> have a great deal of confidence that this is something that is very >> important to the industry, and that the IETF has a critical role to = play. >>=20 >> So, make no mistake, whether we end up as a WG or a BoF between now = and >> Quebec, "we're back" - please send comments, and make your travel or >> remote-attendance plans accordingly if you want to participate. >>=20 >> Jari has asked me to co-chair the session in Quebec. As such, I'd = like to >> take requests for presentation time now. Jari and I will likely begin = the >> session with a scoping overview, as well as a first cut at an >> architecture framework, but there should be some time for a few other >> items. When submitting your request, please identify which of the 5 = areas >> below you think your work applies to as well as the internet-draft, = of >> course. >>=20 >> Thanks, and see you on the list and in Quebec. >>=20 >> - Mark >>=20 >>=20 >> On Jun 29, 2011, at 10:35 AM, Jari Arkko wrote: >>=20 >>> I wanted to provide an update of the situation with this working = group >>> proposal. >>>=20 >>> HOMENET is a new working group proposal, a variation of the >>> HOMEGATE/HOMENET theme that we discussed last year, but this time >>> looking at it from a different angle. The old effort was mostly = focused >>> about what home gateways should do: forwarding, transport, and DNS >>> proxying issues. The new effort is about home networks themselves, = in >>> particular what kind of network architecture and configuration is >>> necessary to support IPv6-based home networks. We view IPv4-based = home >>> networks as "done" at this time (or perhaps as "cannot be changed >>> anyway"). >>>=20 >>> I have been discussing this effort in the background for the last >>> couple of month with Mark Townsley and others, and more publicly = since >>> early June. The proposal has been brought to the IESG, IAB and some >>> directorates for discussion, and we've been going back and forth = whether >>> this is ready to become a working group or needs to be run as a BOF = in >>> Quebec City. The current plan is that the working group proposal = goes to >>> IETF-wide review this week, and if the feedback from the community, = IAB, >>> and the IESG is positive, we will create the working group just in = time >>> for the IETF. Otherwise, the slot reserved in the agenda for the = meeting >>> will be used to run the proposal as a BOF. >>>=20 >>> In any case, I would like to solicit discussion on this topic, and >>> perhaps some early drafts as well. Please comment on the charter at >>> least. >>>=20 >>> Note that the new proposal was called FUN at the time that we = created >>> the list. It has now been renamed back to HOMENET to be more >>> descriptive. The list will be renamed soon as well (current = subscribers >>> will stay). >>>=20 >>> This is the most recent version of the charter we should discuss: >>>=20 >>> Home Networks (homenet) >>> ----------------------------------- >>>=20 >>> Current Status: Proposed >>> Last Edit: Wednesday, June 29th, 2011 >>>=20 >>> Chairs: >>> TBD >>>=20 >>> Internet Area Directors: >>> Ralph Droms >>> Jari Arkko >>>=20 >>> Internet Area Advisor: >>> Jari Arkko >>>=20 >>> Routing Area Technical Advisor: >>> TBD >>>=20 >>> Security Area Technical Advisor: >>> TBD >>>=20 >>> Mailing Lists: >>> General Discussion: fun@ietf.org >>> To Subscribe: https://www.ietf.org/mailman/listinfo/fun >>> Archive: http://www.ietf.org/mail-archive/web/fun >>>=20 >>> Description of Working Group: >>>=20 >>> This working group focuses on the evolving networking technology >>> within and among relatively small =B3residential home=B2 networks. = For >>> example, an obvious trend in home networking is the proliferation of >>> networking technology in an increasingly broad range and number of >>> devices. This evolution in scale and diversity sets some = requirements >>> on IETF protocols. Some of the relevant trends include: >>>=20 >>> o Multiple segments: While less complex L3-toplogies involving as = few >>> subnets as possible are preferred in home networks for a variety of >>> reasons including simpler management and service discovery, the >>> introduction of more than one subnet into a home network is enough >>> to add complexity that needs to be addressed, and multiple >>> dedicated segments are necessary for some cases. For instance, a >>> common feature in modern home routers in the ability to support >>> both guest and private network segments. Also, link layer >>> networking technology is poised to become more heterogeneous, as >>> networks begin to employ both traditional Ethernet technology and >>> link layers designed for low-powered sensor networks. Finally, >>> similar needs for segmentation may occur in other cases, such as >>> separating building control or corporate extensions from the >>> Internet access network. Different segments may be associated with >>> subnets that have different routing and security policies. >>>=20 >>> o Service providers are deploying IPv6, and support for IPv6 is >>> increasingly available in home gateway devices. While IPv6 resembles >>> IPv4 in many ways, it changes address allocation principles and = allows >>> direct IP addressability and routing to devices in the home from the >>> Internet. This is a promising area in IPv6 that has proved = challenging >>> in IPv4 with the proliferation of NAT. >>>=20 >>> o End-to-end communication is both an opportunity and a concern as = it >>> enables new applications but also exposes nodes in the internal >>> networks to receipt of unwanted traffic from the Internet. Firewalls >>> that restrict incoming connections may be used to prevent exposure, >>> however, this reduces the efficacy of end-to-end connectivity that >>> IPv6 has the potential to restore. >>>=20 >>> Home networks need to provide the tools to handle these situations = in >>> a manner accessible to all users of home networks. Manual >>> configuration is rarely, if at all, possible. The purpose of this >>> working group is to focus on this evolution, in particular as it >>> addresses the introduction of IPv6, by developing an architecture >>> addressing this full scope of requirements: >>>=20 >>> o prefix configuration for routers >>> o managing routing >>> o name resolution >>> o service discovery >>> o network security >>>=20 >>> The task of the group is to produce an architecture document that >>> outlines how to construct home networks involving multiple routers = and >>> subnets. This document is expected to apply the IPv6 addressing >>> architecture, prefix delegation, global and ULA addresses, source >>> address selection rules and other existing components of the IPv6 >>> architecture. The architecture document should drive what protocols >>> changes, if any, are necessary. Specific protocol work described = below >>> is expected to be within the scope of the working group one the >>> architecture work is complete. However, the group is required to >>> review its charter and milestones with the IESG and IETF community >>> before submitting documents that make protocol changes. It is = expected >>> that the group has to discuss some of the below solutions, however, = in >>> order to complete the architecture work. >>>=20 >>> The group will apply existing protocols to handle the five >>> requirements above. For prefix configuration, existing protocols are >>> likely sufficient, and at worst may need some small enhancements, = such >>> as new options. For automatic routing, it is expected that existing >>> routing protocols can be used as is, however, a new mechanism may be >>> needed in order to turn a selected protocol on by default. For name >>> resolution and service discovery, extensions to existing >>> multicast-based name resolution protocols are needed to enable them = to >>> work across subnets. >>>=20 >>> For network security, the group shall document the concept of >>> "advanced security" as a further development of "simple security" = from >>> RFC 6092. The main goal of this work is to enable a security policy >>> that adapts to IPv6 threats as they emerge, taking into account not >>> only traffic from the Internet at large, but within and leaving the >>> home network itself. >>>=20 >>> It is expected that the working group will define a set of protocol >>> specifications to accomplish the five requirements from >>> above. However, it is not in the scope of the working group to = define >>> entirely new routing protocols or address allocation protocols. As >>> noted, additional options or other small extensions may be necessary >>> to use the existing protocols in these new configuration tasks. The >>> working group shall also not make any changes to IPv6 protocols or >>> addressing architecture. Prefix configuration, routing, and security >>> related work shall not cause any changes that are not backwards >>> compatible to existing IPv6 hosts. There may be host visible changes >>> in the work on naming and discovery protocols, however. In its = design, >>> the working group shall also consider security aspects and the = impact >>> on manageability. The main focus of the working group is home >>> networks, but the group's results may also find applications in = other >>> small networks. >>>=20 >>> The working group will liaise with the relevant IETF working >>> groups. In particular, the group should work closely with the V6OPS >>> working group, review any use or extension of DHCP with the DHC >>> working group, and work with additional DNS requirements with the >>> DNSEXT and DNSOP working groups. If it turns out that additional >>> options are needed for a routing protocol, they will be developed in >>> the appropriate Routing Area working group, with the HOMENET working >>> group providing the architecture and requirements for such >>> enhancements. The working group will also liase with external >>> standards bodies where it is expected that there are normative >>> dependencies between the specifications of the two bodies. >>> It is expected that in the architecture definition stage liaising >>> with the Broadband Forum, DLNA, and UPnP Forum is necessary. >>>=20 >>> Milestones: >>>=20 >>> Jul 2011 Formation of the working group >>> Sep 2011 First WG draft on the architecture >>> Dec 2011 Submission of the architecture draft to the IESG as >>> Informational RFC >>> Dec 2011 Charter re-evaluation based on the architecture work >>> Dec 2011 First WG draft on prefix configuration >>> Dec 2011 First WG draft on routing >>> Jan 2012 First WG draft on name resolution >>> Feb 2012 First WG draft on service discovery >>> Feb 2012 First WG draft on perimeter security >>> Feb 2012 Start of routing related work in the relevant routing area >>> working group, if needed >>> Mar 2012 Submission of the prefix configuration draft to the IESG as >>> Standards Track RFC >>> Apr 2012 Submission of the routing draft to the IESG as = Informational >>> RFC >>> Sep 2012 Submission of the name resolution draft to the IESG as >>> Standards Track RFC >>> Nov 2012 Submission of the service discovery draft to the IESG as >>> Standards Track RFC >>> Dec 2012 Submission of the perimeter security draft to the IESG as >>> Informational RFC >>>=20 >>> _______________________________________________ >>> fun mailing list >>> fun@ietf.org >>> https://www.ietf.org/mailman/listinfo/fun >>=20 >> _______________________________________________ >> fun mailing list >> fun@ietf.org >> https://www.ietf.org/mailman/listinfo/fun >=20 >=20 > This E-mail and any of its attachments may contain Time Warner Cable = proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended = solely for the use of the individual or entity to which it is addressed. = If you are not the intended recipient of this E-mail, you are hereby = notified that any dissemination, distribution, copying, or action taken = in relation to the contents of and attachments to this E-mail is = strictly prohibited and may be unlawful. If you have received this = E-mail in error, please notify the sender immediately and permanently = delete the original and any copy of this E-mail and any printout. From moore@network-heretics.com Thu Jun 30 09:36:58 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D12511E8255; Thu, 30 Jun 2011 09:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RLizpg-a-mYA; Thu, 30 Jun 2011 09:36:57 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id C2D5111E8247; Thu, 30 Jun 2011 09:36:55 -0700 (PDT) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.messagingengine.com (Postfix) with ESMTP id 70064206A8; Thu, 30 Jun 2011 12:36:55 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute5.internal (MEProxy); Thu, 30 Jun 2011 12:36:55 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=tTBwDGnemCORVN38Co+zkkB4Ezs=; b=Vh03ebhwSaCkchOF/nVJaQTrgwflglwy4jZkQ20PXqMEHRqTXFbDu+/Zc0UzK+1lUEFCYOJHQJldFpwMv4nP4B6Jcp1C1hpr8GxFxVx0QdVW2wuoUhmaM3/8CRnX04LFT643mG9kJrR7EH+3acdYDpn4fDl/8tanIlzHyYiAy6g= X-Sasl-enc: 8/SypNtsIltWK8Y/YUYnihNlVq1/HhCoEnJWvsho6SS4 1309451814 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 61B16409DFC; Thu, 30 Jun 2011 12:36:54 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <780C3063-AD82-46F3-874A-C4E1E61EE508@townsley.net> Date: Thu, 30 Jun 2011 12:36:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E0AE696.4020603@piuha.net> <4E0BDCF3.1090003@gont.com.ar> <4E0C1CF8.7090601@gont.com.ar> <558D0669-8B2A-4514-B3FB-C690C40A4EF8@townsley.net> <0F995E91-9853-4018-91F0-0699E1A7A06F@network-heretics.com> <780C3063-AD82-46F3-874A-C4E1E61EE508@townsley.net> To: Mark Townsley X-Mailer: Apple Mail (2.1084) Cc: IETF Discussion , fun@ietf.org, homegate@ietf.org Subject: Re: [fun] [homegate] HOMENET working group proposal X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 16:36:58 -0000 On Jun 30, 2011, at 12:33 PM, Mark Townsley wrote: >>>=20 >>> I think the consensus we had in the past BoFs and discussion in and = around this topic can be summed up as stating that homenet deliverables = will: >>>=20 >>> - coexist with (existing) IPv4 protocols, devices, applications, = etc. >>> - operate in a (future) IPv6-only home network in the absence of = IPv4 >>> - be IP-agnostic whenever possible >>=20 >> I'd like for this group to relax the "wherever possible" bit, so as = to not preclude solutions where IPv6 can do a better job than IPv4. >=20 > Yes, and I think that IPv6 should naturally do a better job than IPv4 = in the cases where it can.=20 >=20 > My original mail had this restatement of the above, which I think gets = closer to what you want: >=20 >>> However, when we can define something that is needed for IPv6 in a = way that is also useful for IPv4 without making significant concessions, = we should go ahead and do so. when the group can define something that is useful in IPv6, it shouldn't = matter whether it's also useful for IPv4. please don't constrain home networks to work only within the confines of = IPv4 brain damage. Keith From jari.arkko@piuha.net Thu Jun 30 10:19:17 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FAFC11E827D for ; Thu, 30 Jun 2011 10:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.004 X-Spam-Level: X-Spam-Status: No, score=-102.004 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YmAMyaHEqflN for ; Thu, 30 Jun 2011 10:19:16 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0B111E827C for ; Thu, 30 Jun 2011 10:19:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 78AE02CEA0 for ; Thu, 30 Jun 2011 20:19:07 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id luf0FspANzKR for ; Thu, 30 Jun 2011 20:19:05 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id C63782CC39 for ; Thu, 30 Jun 2011 20:19:05 +0300 (EEST) Message-ID: <4E0CB009.9070104@piuha.net> Date: Thu, 30 Jun 2011 19:19:05 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: "fun@ietf.org" References: <4E0AE3CF.2070504@piuha.net> In-Reply-To: <4E0AE3CF.2070504@piuha.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [fun] status of the homenet effort X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 17:19:17 -0000 This is just an update that the IESG approved the below charter for external review in its meeting today. "For external review" means that IETF participants and other people are formally asked to comment on it. The review period runs until July 14th. Jari Home Networks (homenet) ----------------------------------- Current Status: Proposed Last Edit: Wednesday, June 30th, 2011 Chairs: TBD Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Routing Area Technical Advisor: TBD Security Area Technical Advisor: TBD Mailing Lists: General Discussion: fun@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/fun Archive: http://www.ietf.org/mail-archive/web/fun Description of Working Group: This working group focuses on the evolving networking technology within and among relatively small “residential home” networks. For example, an obvious trend in home networking is the proliferation of networking technology in an increasingly broad range and number of devices. This evolution in scale and diversity sets some requirements on IETF protocols. Some of the relevant trends include: o Multiple segments: While less complex L3-toplogies involving as few subnets as possible are preferred in home networks for a variety of reasons including simpler management and service discovery, the introduction of more than one subnet into a home network is enough to add complexity that needs to be addressed, and multiple dedicated segments are necessary for some cases. For instance, a common feature in modern home routers in the ability to support both guest and private network segments. Also, link layer networking technology is poised to become more heterogeneous, as networks begin to employ both traditional Ethernet technology and link layers designed for low-powered sensor networks. Finally, similar needs for segmentation may occur in other cases, such as separating building control or corporate extensions from the Internet access network. Different segments may be associated with subnets that have different routing and security policies. o Service providers are deploying IPv6, and support for IPv6 is increasingly available in home gateway devices. While IPv6 resembles IPv4 in many ways, it changes address allocation principles and allows direct IP addressability and routing to devices in the home from the Internet. This is a promising area in IPv6 that has proved challenging in IPv4 with the proliferation of NAT. o End-to-end communication is both an opportunity and a concern as it enables new applications but also exposes nodes in the internal networks to receipt of unwanted traffic from the Internet. Firewalls that restrict incoming connections may be used to prevent exposure, however, this reduces the efficacy of end-to-end connectivity that IPv6 has the potential to restore. Home networks need to provide the tools to handle these situations in a manner accessible to all users of home networks. Manual configuration is rarely, if at all, possible, as the necessary skills and in some cases even suitable management interfaces are missing. The purpose of this working group is to focus on this evolution, in particular as it addresses the introduction of IPv6, by developing an architecture addressing this full scope of requirements: o prefix configuration for routers o managing routing o name resolution o service discovery o network security The task of the group is to produce an architecture document that outlines how to construct home networks involving multiple routers and subnets. This document is expected to apply the IPv6 addressing architecture, prefix delegation, global and ULA addresses, source address selection rules and other existing components of the IPv6 architecture. The architecture document should drive what protocols changes, if any, are necessary. Specific protocol work described below is expected to be within the scope of the working group once the architecture work is complete. However, the group is required to review its charter and milestones with the IESG and IETF community before submitting documents that make protocol changes. It is expected that the group has to discuss some of the below solutions, however, in order to complete the architecture work. The group will apply existing protocols to handle the five requirements above. For prefix configuration, existing protocols are likely sufficient, and at worst may need some small enhancements, such as new options. For automatic routing, it is expected that existing routing protocols can be used as is, however, a new mechanism may be needed in order to turn a selected protocol on by default. For name resolution and service discovery, extensions to existing multicast-based name resolution protocols are needed to enable them to work across subnets. For network security, the group shall document the concept of "advanced security" as a further development of "simple security" from RFC 6092. The main goal of this work is to enable a security policy that adapts to IPv6 threats as they emerge, taking into account not only traffic from the Internet at large, but within and leaving the home network itself. It is expected that the working group will define a set of protocol specifications to accomplish the five requirements from above. However, it is not in the scope of the working group to define entirely new routing protocols or address allocation protocols. As noted, additional options or other small extensions may be necessary to use the existing protocols in these new configuration tasks. The working group shall also not make any changes to IPv6 protocols or addressing architecture. Prefix configuration, routing, and security related work shall not cause any changes that are not backwards compatible to existing IPv6 hosts. There may be host visible changes in the work on naming and discovery protocols, however. In its design, the working group shall also consider security aspects and the impact on manageability. The main focus of the working group is home networks, but the group's results may also find applications in other small networks. The working group will liaise with the relevant IETF working groups. In particular, the group should work closely with the V6OPS working group, review any use or extension of DHCP with the DHC working group, and work with additional DNS requirements with the DNSEXT and DNSOP working groups. If it turns out that additional options are needed for a routing protocol, they will be developed in the appropriate Routing Area working group, with the HOMENET working group providing the architecture and requirements for such enhancements. The working group will also liase with external standards bodies where it is expected that there are normative dependencies between the specifications of the two bodies. It is expected that in the architecture definition stage liaising with the Broadband Forum, DLNA, and UPnP Forum is necessary. Milestones: Jul 2011 Formation of the working group Sep 2011 First WG draft on the architecture Dec 2011 Submission of the architecture draft to the IESG as Informational RFC Dec 2011 Charter re-evaluation based on the architecture work Dec 2011 First WG draft on prefix configuration Dec 2011 First WG draft on routing Jan 2012 First WG draft on name resolution Feb 2012 First WG draft on service discovery Feb 2012 First WG draft on perimeter security Feb 2012 Start of routing related work in the relevant routing area working group, if needed Mar 2012 Submission of the prefix configuration draft to the IESG as Standards Track RFC Apr 2012 Submission of the routing draft to the IESG as Informational RFC Sep 2012 Submission of the name resolution draft to the IESG as Standards Track RFC Nov 2012 Submission of the service discovery draft to the IESG as Standards Track RFC Dec 2012 Submission of the perimeter security draft to the IESG as Informational RFC From jhw@apple.com Thu Jun 30 11:21:21 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F33F09E800D; Thu, 30 Jun 2011 11:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfIedxz3ddvX; Thu, 30 Jun 2011 11:21:20 -0700 (PDT) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 6993E9E801B; Thu, 30 Jun 2011 11:21:20 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay13.apple.com ([17.128.113.29]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LNM00JDQ8AP3EW0@mail-out.apple.com>; Thu, 30 Jun 2011 11:21:14 -0700 (PDT) X-AuditID: 1180711d-b7c5fae000001427-ef-4e0cbe816c23 Received: from jimbu (jimbu.apple.com [17.151.62.37]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay13.apple.com (Apple SCV relay) with SMTP id 3D.87.05159.18EBC0E4; Thu, 30 Jun 2011 11:20:49 -0700 (PDT) Received: from [17.193.13.64] (unknown [17.193.13.64]) by cardamom.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LNM00K208BDZS70@cardamom.apple.com>; Thu, 30 Jun 2011 11:21:13 -0700 (PDT) From: james woodyatt In-reply-to: Date: Thu, 30 Jun 2011 11:21:13 -0700 Message-id: <5C263F1C-A180-4EFC-A44F-3E867C6CF4DC@apple.com> References: <4E0AE696.4020603@piuha.net> <4E0BDCF3.1090003@gont.com.ar> <4E0C1CF8.7090601@gont.com.ar> <558D0669-8B2A-4514-B3FB-C690C40A4EF8@townsley.net> <0F995E91-9853-4018-91F0-0699E1A7A06F@network-heretics.com> <780C3063-AD82-46F3-874A-C4E1E61EE508@townsley.net> To: fun@ietf.org X-Mailer: Apple Mail (2.1244.3) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNLMWRmVeSWpSXmKPExsUiON1OVbdxH4+fwc85KhaPD8xit3i2cT6L A5PHkiU/mQIYo7hsUlJzMstSi/TtErgyzl49yV7QwlEx6c0O5gbGfWxdjJwcEgImEtdevWCC sMUkLtxbDxTn4hASaGWSaOh6xAiS4BUQlPgx+R5LFyMHB7OAvMTB87IgYWYBLYnvj1pZIOrb mSS29J9mAUkIC5hJdF39wQxiswmoSHy7fBdsAaeAh8TKpp/sIDaLgKrEisYONohByhJvzvxn gthlI7Fx6kt2iKGHmCVuP+gGaxAREJDYOe0OO8Sl8hKLWz4zTmAUmIXkvlkI981Cct8CRuZV jIJFqTmJlYbGeokFBTmpesn5uZsYQUHYUCi7g3H/T/5DjAIcjEo8vCcn8vgJsSaWFVfmHmKU 4GBWEuFdVQ0U4k1JrKxKLcqPLyrNSS0+xCjNwaIkzhuTye0nJJCeWJKanZpakFoEk2Xi4JRq YAxNOas+x2J2TMyEP7P/Hzh32Y3h3sfWY5I7l1V5twaJeK7ccuWAUZL3EvaMhNWWu5Vqv8+q eG89V0fI8cmm8om7bX1OJj5XUOI1mXnt9pne7yJrTz67y6sWOXdL/x3LBpbQC0fLp/AUnhaN 9K96FsOimH57lQyzxMl3W6K3Pfr0fN3Nde6x134rsRRnJBpqMRcVJwIAlMclgj4CAAA= Cc: IETF Discussion Subject: Re: [fun] [homegate] HOMENET working group proposal X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 18:21:21 -0000 On Jun 30, 2011, at 09:36 , Keith Moore wrote: > > when the group can define something that is useful in IPv6, it shouldn't matter whether it's also useful for IPv4. > please don't constrain home networks to work only within the confines of IPv4 brain damage. I suspect what Mr. Townsley and Mr. Arkko are aiming at here is that if FUN can come up with a scheme to make routed home subnetworks work with delegated IPv6 prefixes, then it is probably not too far-fetched that the same scheme could be trivially extended for assigning IPv4 subnets from the RFC 1918 private realm to support dual-stack routed home subnetworks. I'm not expecting home networks to be able to run IPv6-only with the IPv4 Internet mapped to 64:ff9b::/96 through NAT64 for several more years yet. There's a whole crapload of legacy IPv4-only devices in the average home theater system today that nobody wants to cut off from the Internet just yet. -- james woodyatt member of technical staff, core os networking From EArthurs@golegacy.com Thu Jun 30 11:33:46 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0D429E8038 for ; Thu, 30 Jun 2011 11:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 4Ppp22RHip+i for ; Thu, 30 Jun 2011 11:33:46 -0700 (PDT) Received: from GOLEGACY.COM (mail.golegacy.com [208.179.230.34]) by ietfa.amsl.com (Postfix) with ESMTP id E43509E8037 for ; Thu, 30 Jun 2011 11:33:45 -0700 (PDT) Received: from eldiablo [172.25.2.14] by GOLEGACY.COM with ESMTP (SMTPD32-8.15) id A32F33FF0052; Thu, 30 Jun 2011 11:40:47 -0700 From: "Edward Arthurs" To: Date: Thu, 30 Jun 2011 11:40:47 -0700 Organization: Legacy International Inc. Message-ID: <268801cc3755$3a2801b0$0e0219ac@GOLEGACYINC.COM> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_2689_01CC371A.8DC929B0" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acw3VToNrQZ/MT9kR/WIaAo0wifrew== X-Mailman-Approved-At: Thu, 30 Jun 2011 14:29:28 -0700 Subject: Re: [fun] [homegate] HOMENET working group proposal X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: EArthurs@golegacy.com List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 18:33:46 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_2689_01CC371A.8DC929B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The only thing aside from the network end that I see is people who have figured out the IPv4 scheme. Now have to figure out the IPv6 scheme, and the size has of the I.P. address has them scratching their heads, not everyone has heard of IPv6 yet. Thank You Edward Arthurs Manager of Network Installations Legacy Inmate Communications Legacy Contact Center Legacy Long Distance Intl. Inc 10833 Valley View Street Suite 150 Cypress, California 90630-5040 Office 1-800-577-5534 ext. 207 Direct 1-800-956-1595 Fax 1-714-827-7545 E-Mail: earthurs@golegacy.com E-Mail: earthurs@vzw.blackberry.net This e-mail (including any attachments) may contain information that is private, confidential, or protected by attorney-client or other privilege. If you received this e-mail in error, please delete it from your system without copying it and notify sender by reply e-mail, so that our records can be corrected. No trees were harmed as a result of this e-mail; however, many electrons were severely inconvenienced. ------=_NextPart_000_2689_01CC371A.8DC929B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The only thing aside from the network end that I see = is people who have figured out the IPv4 = scheme.

Now have to figure out the IPv6 scheme, and the size = has of the I.P. address has them scratching their heads, not everyone has heard = of IPv6 yet.

 

Thank You

 

Edward Arthurs

Manager of Network = Installations

Legacy Inmate = Communications

Legacy Contact Center

Legacy Long Distance Intl. = Inc

10833 = Valley View Street

Suite = 150

Cypress, California 90630-5040

Office 1-800-577-5534 ext. = 207

Direct 1-800-956-1595

Fax    = 1-714-827-7545

E-Mail: earthurs@golegacy.com

E-Mail: earthurs@vzw.blackberry.net

 

 

This e-mail (including any attachments) may contain information that is private, confidential, or protected by = attorney-client or other privilege.

If you received this e-mail in error, please delete it = from your system without copying it and notify sender by reply e-mail, so = that our records can be corrected.

No trees were harmed as a result of this e-mail; = however, many electrons were severely = inconvenienced.

 

 

------=_NextPart_000_2689_01CC371A.8DC929B0-- From robert@raszuk.net Thu Jun 30 16:11:00 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D75B11E82DF; Thu, 30 Jun 2011 16:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7znbedDnQgO3; Thu, 30 Jun 2011 16:10:59 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by ietfa.amsl.com (Postfix) with ESMTP id 452FA11E82CB; Thu, 30 Jun 2011 16:10:59 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAEcBDU6tJV2c/2dsb2JhbABSp153qkSdZ4YxBJIvhHaLOg X-IronPort-AV: E=Sophos;i="4.65,455,1304294400"; d="scan'208";a="238874412" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-2.cisco.com with ESMTP; 30 Jun 2011 23:10:58 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p5UNAuAl018375; Thu, 30 Jun 2011 23:10:57 GMT Message-ID: <4E0D0281.3020608@raszuk.net> Date: Fri, 01 Jul 2011 01:10:57 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: fun@ietf.org, homegate@ietf.org References: <4E0AE696.4020603@piuha.net> <4E0BDCF3.1090003@gont.com.ar> <4E0C1CF8.7090601@gont.com.ar> <558D0669-8B2A-4514-B3FB-C690C40A4EF8@townsley.net> <0F995E91-9853-4018-91F0-0699E1A7A06F@network-heretics.com> <780C3063-AD82-46F3-874A-C4E1E61EE508@townsley.net> In-Reply-To: <780C3063-AD82-46F3-874A-C4E1E61EE508@townsley.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [fun] [homegate] HOMENET working group proposal X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 23:11:00 -0000 I think this is a great WG proposal and I fully support it's creation. However my ISP is telling me that it has sufficient pool of IPv4 addresses for the min next 5-10 years so rolling v6 for residential users is completely not that much appealing to him. IETF can build many specs recommending v6 deployments, protocol extensions and network architectures. Unfortunately before the day when there is first attractive real content available online _only_ via v6 or when there is new killer app which works only over v6 I think the world will become more and more fragmented into islands of v4, v4v6 and v6 only. The issue is not technical here and IETF will not I am afraid be able to fix it. The issue is purely business driven and till all providers get clear message from their users that they must have v6 as they can not google anymore, pay their bills, use new fancy holographic movie downloader app (just as examples) the migration towards v6 may take not 10 but 50 to 100 years. Cheers, R. From marka@isc.org Thu Jun 30 16:20:49 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77D3411E8122; Thu, 30 Jun 2011 16:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.685 X-Spam-Level: X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1egcnvQxQK0F; Thu, 30 Jun 2011 16:20:48 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 5BFC111E810E; Thu, 30 Jun 2011 16:20:48 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 5DF44C94CF; Thu, 30 Jun 2011 23:20:39 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id E8617216C82; Thu, 30 Jun 2011 23:20:38 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 860E911532DE; Fri, 1 Jul 2011 09:20:35 +1000 (EST) To: james woodyatt From: Mark Andrews References: <4E0AE696.4020603@piuha.net> <4E0BDCF3.1090003@gont.com.ar> <4E0C1CF8.7090601@gont.com.ar> <558D0669-8B2A-4514-B3FB-C690C40A4EF8@townsley.net> <0F995E91-9853-4018-91F0-0699E1A7A06F@network-heretics.com> <780C3063-AD82-46F3-874A-C4E1E61EE508@townsley.net> <5C263F1C-A180-4EFC-A44F-3E867C6CF4DC@apple.com> In-reply-to: Your message of "Thu, 30 Jun 2011 11:21:13 MST." <5C263F1C-A180-4EFC-A44F-3E867C6CF4DC@apple.com> Date: Fri, 01 Jul 2011 09:20:35 +1000 Message-Id: <20110630232035.860E911532DE@drugs.dv.isc.org> Cc: fun@ietf.org, IETF Discussion Subject: Re: [fun] [homegate] HOMENET working group proposal X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 23:20:49 -0000 In message <5C263F1C-A180-4EFC-A44F-3E867C6CF4DC@apple.com>, james woodyatt wri tes: > On Jun 30, 2011, at 09:36 , Keith Moore wrote: > > > > when the group can define something that is useful in IPv6, it shouldn't ma > tter whether it's also useful for IPv4. > > please don't constrain home networks to work only within the confines of IP > v4 brain damage. > > I suspect what Mr. Townsley and Mr. Arkko are aiming at here is that if FUN c > an come up with a scheme to make routed home subnetworks work with delegated > IPv6 prefixes, then it is probably not too far-fetched that the same scheme c > ould be trivially extended for assigning IPv4 subnets from the RFC 1918 priva > te realm to support dual-stack routed home subnetworks. > > I'm not expecting home networks to be able to run IPv6-only with the IPv4 Int > ernet mapped to 64:ff9b::/96 through NAT64 for several more years yet. There > 's a whole crapload of legacy IPv4-only devices in the average home theater s > ystem today that nobody wants to cut off from the Internet just yet. I'm expecting home nets to be dual stacked for 10+ years after IPv6 is common to the home (2-5) years. If the home gateway has DS-Lite support then that provides a better solution than NAT 444. It also continues to work when the home net goes IPv6 only with the home gateway passing on the DS-Lite parameters from the ISP. Consumer electronics lasts 10+ years. I'm still using my DOCSIS 1.0 modem 8+ years. My router hardware is 13+ years old, the software is newer and is the 6in4 tunnel end point. I've got TV's of similar vintage. > -- > james woodyatt > member of technical staff, core os networking > > > > _______________________________________________ > fun mailing list > fun@ietf.org > https://www.ietf.org/mailman/listinfo/fun -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From jhw@apple.com Thu Jun 30 16:51:31 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05A0211E8080; Thu, 30 Jun 2011 16:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bd0bo+7HWO7i; Thu, 30 Jun 2011 16:51:30 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 75324228010; Thu, 30 Jun 2011 16:51:30 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay11.apple.com ([17.128.113.48]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LNM007I6NKMIBF1@mail-out.apple.com>; Thu, 30 Jun 2011 16:51:29 -0700 (PDT) X-AuditID: 11807130-b7c45ae000001381-d7-4e0d0be80dd0 Received: from jimbu (jimbu.apple.com [17.151.62.37]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay11.apple.com (Apple SCV relay) with SMTP id 80.95.04993.8EB0D0E4; Thu, 30 Jun 2011 16:51:04 -0700 (PDT) Received: from [17.193.13.64] (unknown [17.193.13.64]) by cardamom.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LNM006UUNLT4Q20@cardamom.apple.com>; Thu, 30 Jun 2011 16:51:29 -0700 (PDT) From: james woodyatt In-reply-to: <4E0D0281.3020608@raszuk.net> Date: Thu, 30 Jun 2011 16:51:29 -0700 Message-id: References: <4E0AE696.4020603@piuha.net> <4E0BDCF3.1090003@gont.com.ar> <4E0C1CF8.7090601@gont.com.ar> <558D0669-8B2A-4514-B3FB-C690C40A4EF8@townsley.net> <0F995E91-9853-4018-91F0-0699E1A7A06F@network-heretics.com> <780C3063-AD82-46F3-874A-C4E1E61EE508@townsley.net> <4E0D0281.3020608@raszuk.net> To: fun@ietf.org, homegate@ietf.org X-Mailer: Apple Mail (2.1244.3) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPLMWRmVeSWpSXmKPExsUiON1OVfcFN6+fwckeI4vHB2axW2y71M/m wOSxZMlPpgDGKC6blNSczLLUIn27BK6MhhX7mQt28VVM3PSNtYHxFXcXIyeHhICJxPkjsxkh bDGJC/fWs3UxcnEICbQySexaPZkJJMErICjxY/I9li5GDg5mAXmJg+dlQcLMAloS3x+1skDU tzNJPJj/kh0kISxgI9G4eyIbiM0moCLx7fJdsDmcQA1nz0xjAbFZBFQlnh7+xgYx30bicd9E RohBS5glTp9bCTZIREAZ6Loz7BDXyUssbvnMOIGRfxaSm2Yh3DQLyU0LGJlXMQoWpeYkVhoa 6iUWFOSk6iXn525iBAVbQ6HBDsa1P/kPMQpwMCrx8CpM4fETYk0sK67MPcQowcGsJMK7qhoo xJuSWFmVWpQfX1Sak1p8iFGag0VJnDc2k9tPSCA9sSQ1OzW1ILUIJsvEwSnVwLhdneOn8KRJ s1tqNZPW8nNNlNma/GAhx3vx11fKM0N1T6ZqlHoxsCRG5se6TOSYe3HqrrTv86XrhI0O7rry Jc1ztU3d/VdvHpvI2Z86uGyiccQi+2v1wUK+82d9nuB2XHBfFc/+JZMkbLm6P89KTOGaOOXs sdsfd67re7/ko1BApRlP3ZIz72YqsRRnJBpqMRcVJwIAvBke1jICAAA= Subject: Re: [fun] [homegate] HOMENET working group proposal X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 23:51:31 -0000 On Jun 30, 2011, at 16:10 , Robert Raszuk wrote: > > ...when there is new killer app which works only over v6... There's another conditional that may be more relevant. When there is a new "killer" application that doesn't work when one endpoint is IPv4-only and the other is attached to a 3GPP network with IPv6-only service and using NAT64 with the well-known 64:ff9b::/64 prefix, and optionally a bump-in-the-host to provide an IPv4 networking API to applications. I happen to be aware of a whole family of interesting applications that are broken by such configurations, and I'm pretty sure they will remain broken into the foreseeable future. Those configurations are already here in some parts of the Internet, and when these applications I'm thinking about are deployed on those networks (they are not currently, but... mene mene tekel upharsin), they will fail. And whose fault will that be? Not mine, brother. Not mine. Is your service provider breaking those awesome applications by not offering full dual-stack service? If so, then you need to get a new service provider. Either get one that offers full dual-stack over 3GPP so your applications can connect with IPv4-only endpoints, or get one that offers full dual-stack over first-mile wireline to your site, so your applications can connect to IPv4-impaired mobile endpoints. The key thing here is that by Alice choosing to use one service provider over another, she can make Bob's application fail, and vice versa. The mobile service providers that don't have enough IPv4 addresses to serve all their customers are in a bind and can't budge. The wireline service providers who have 5-10 years of IPv4 addresses in reserve are the ones whistling past the graveyard. -- james woodyatt member of technical staff, core os networking From swmike@swm.pp.se Thu Jun 30 22:23:51 2011 Return-Path: X-Original-To: fun@ietfa.amsl.com Delivered-To: fun@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB1F11E80D6; Thu, 30 Jun 2011 22:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7u2zNg8YKBsP; Thu, 30 Jun 2011 22:23:50 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 6C96811E80D0; Thu, 30 Jun 2011 22:23:49 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 17F989C; Fri, 1 Jul 2011 07:23:47 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 15D569A; Fri, 1 Jul 2011 07:23:47 +0200 (CEST) Date: Fri, 1 Jul 2011 07:23:47 +0200 (CEST) From: Mikael Abrahamsson To: Martin Focazio In-Reply-To: <-4529087406481929693@unknownmsgid> Message-ID: References: <4E0AE696.4020603@piuha.net> <4E0BDCF3.1090003@gont.com.ar> <4E0C1CF8.7090601@gont.com.ar> <558D0669-8B2A-4514-B3FB-C690C40A4EF8@townsley.net> <0F995E91-9853-4018-91F0-0699E1A7A06F@network-heretics.com> <780C3063-AD82-46F3-874A-C4E1E61EE508@townsley.net> <4E0D0281.3020608@raszuk.net> <-4529087406481929693@unknownmsgid> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "homegate@ietf.org" , "fun@ietf.org" Subject: Re: [fun] [homegate] HOMENET working group proposal X-BeenThere: fun@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "FUture home Networking \(FUN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 05:23:51 -0000 On Thu, 30 Jun 2011, Martin Focazio wrote: > You assume at Alice CAN select a service provider. In a large part of > the USA your choices are nil. You have a single wireline provider or > you don't have a connection. I don't see why the IETF should spend time on IPv4 because of some political problem in certain countries which makes the market not work properly. IPv4 is legacy, IPv6 is where the development effort should be, when IPv6 offers more functionality then things will most likely sort themselves out. Personally I believe video conferencing is the killer app. I have problems getting video calls to work when both are behind NAT, it works just fine with one person being behind NAT (and the other one not having firewall configured so it's stopping the traffic). With IPv6 we just need to sort out the firewall problem. My mom is very impressed by being able to videocall her grandchild and follow his development, and if I told her it'd cost 200 USD extra to make it work (better), either she or I would spend the money. -- Mikael Abrahamsson email: swmike@swm.pp.se