From jari.arkko@piuha.net Wed Jun 29 01:47:30 2011 Return-Path: X-Original-To: homegate@ietfa.amsl.com Delivered-To: homegate@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF36811E80A1; Wed, 29 Jun 2011 01:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.048 X-Spam-Level: X-Spam-Status: No, score=-102.048 tagged_above=-999 required=5 tests=[AWL=-0.049, 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 e409bcx4Xdab; Wed, 29 Jun 2011 01:47:29 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 03C2C21F86A1; Wed, 29 Jun 2011 01:47:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 22C512CC3B; Wed, 29 Jun 2011 11:47:26 +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 4NEFIdMMzeAl; Wed, 29 Jun 2011 11:47:20 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 080C02CC39; Wed, 29 Jun 2011 11:47:18 +0300 (EEST) Message-ID: <4E0AE696.4020603@piuha.net> Date: Wed, 29 Jun 2011 10:47:18 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: "homegate@ietf.org" , IETF Discussion Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: [homegate] HOMENET working group proposal X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Broadband Home Gateway Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 08:47:30 -0000 I would like to announce a new effort around home networking and solicit some feedback. 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. Go here to subscribe https://www.ietf.org/mailman/listinfo/fun and below you can find the most recent charter proposal. Please join the list and the discussion. 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). Note also that I'm sending this to the old homegate list, to inform people who were interested in that. I'd like the discussion to happen on the fun@ietf.org list, however. Jari 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: homegate@ietfa.amsl.com Delivered-To: homegate@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) Subject: Re: [homegate] [fun] status of the homenet effort X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Broadband Home Gateway Discussion 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 fernando.gont.netbook.win@gmail.com Wed Jun 29 19:18:53 2011 Return-Path: X-Original-To: homegate@ietfa.amsl.com Delivered-To: homegate@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2354411E80B7; Wed, 29 Jun 2011 19:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.845 X-Spam-Level: X-Spam-Status: No, score=-0.845 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_BELOW2=2.154, 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 th8yixeSksiw; Wed, 29 Jun 2011 19:18:52 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id AC26211E8072; Wed, 29 Jun 2011 19:18:48 -0700 (PDT) Received: by ywp31 with SMTP id 31so914432ywp.31 for ; Wed, 29 Jun 2011 19:18: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=5R1kl567g64jluzP6JJoCOuLzwQdjltc/wElb7GRDE4=; b=OD5+MOcAE4Kb3XF4NjSp7e5fvgRQ4T5MhIXYsUF2Aghxe21tLFF0FCp+GgXKAg6Ovv AnSG2nxKQA9XF4q4Ri5dbcH3T1qfcwkz8FtB7/waFlWtfhmw16/sj0rmM1dxovSmYH1o W9FVI57zNALTx9rvaeTHmjyRNO2iWFNwqnxjc= Received: by 10.91.151.20 with SMTP id d20mr1391642ago.19.1309400328019; Wed, 29 Jun 2011 19:18:48 -0700 (PDT) Received: from [192.168.123.103] ([190.48.223.58]) by mx.google.com with ESMTPS id y15sm1579479ann.44.2011.06.29.19.18.30 (version=SSLv3 cipher=OTHER); Wed, 29 Jun 2011 19:18:46 -0700 (PDT) Sender: Fernando Gont Message-ID: <4E0BDCF3.1090003@gont.com.ar> Date: Wed, 29 Jun 2011 23:18:27 -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> In-Reply-To: <4E0AE696.4020603@piuha.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 29 Jun 2011 20:39:36 -0700 Cc: "homegate@ietf.org" , IETF Discussion Subject: Re: [homegate] HOMENET working group proposal X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Broadband Home Gateway Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 02:18:53 -0000 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, 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. 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! -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From cb.list6@gmail.com Wed Jun 29 19:38:39 2011 Return-Path: X-Original-To: homegate@ietfa.amsl.com Delivered-To: homegate@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4FE621F8641; Wed, 29 Jun 2011 19:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.844 X-Spam-Level: X-Spam-Status: No, score=-0.844 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_BELOW2=2.154, HTML_MESSAGE=0.001, 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 HN8h2CLAetHB; Wed, 29 Jun 2011 19:38:39 -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 8F7A821F8640; Wed, 29 Jun 2011 19:38:38 -0700 (PDT) Received: by wyj26 with SMTP id 26so1421862wyj.31 for ; Wed, 29 Jun 2011 19:38:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ph5hfhyPyWKmcFgm8+2CEinWBQnSXS+Q9rGdTtzOpRg=; b=yAqnlrRQRUpQ3/xbJ2sZtkSRLQWivyAd3N1uKZvPhFLbPNmWMPoHqjjWcx5Ox39FvL x6uNBb9gRMjn7ytYSaz4xpbVvbzJdZOYReN8gGVAGnwHr9w0Puh+PKim8KRHFwK42SYh OvCFtJXxHCA2WPQfb/o6MDKV6K2IPuqRVPDj4= MIME-Version: 1.0 Received: by 10.216.158.198 with SMTP id q48mr1200283wek.94.1309401517597; Wed, 29 Jun 2011 19:38:37 -0700 (PDT) Received: by 10.216.39.83 with HTTP; Wed, 29 Jun 2011 19:38:37 -0700 (PDT) Received: by 10.216.39.83 with HTTP; Wed, 29 Jun 2011 19:38:37 -0700 (PDT) In-Reply-To: <4E0BDCF3.1090003@gont.com.ar> References: <4E0AE696.4020603@piuha.net> <4E0BDCF3.1090003@gont.com.ar> Date: Wed, 29 Jun 2011 19:38:37 -0700 Message-ID: From: Cameron Byrne To: Fernando Gont Content-Type: multipart/alternative; boundary=0016367fb5f95324b804a6e4ccc1 X-Mailman-Approved-At: Wed, 29 Jun 2011 20:39:36 -0700 Cc: IETF Discussion , "homegate@ietf.org" Subject: Re: [homegate] HOMENET working group proposal X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Broadband Home Gateway Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 02:38:40 -0000 --0016367fb5f95324b804a6e4ccc1 Content-Type: text/plain; charset=ISO-8859-1 On Jun 29, 2011 7:19 PM, "Fernando Gont" wrote: > > 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, 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. > > 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. > The opportunity for restoring e2e is one of the great opportunities of ipv6 and it is my hope this new WG will drive that with facts and take on fud. The utility of network based spi firewalls is debatable. Likely a never ending debate. Cb > Thanks! > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf --0016367fb5f95324b804a6e4ccc1 Content-Type: text/html; charset=ISO-8859-1


On Jun 29, 2011 7:19 PM, "Fernando Gont" <fernando@gont.com.ar> wrote:
>
> 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, 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.
>
> 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.
>

The opportunity for restoring e2e is one of the great opportunities of ipv6 and it is my hope this new WG will drive that with facts and take on fud.

The utility of network based spi firewalls is debatable. Likely a never ending debate.

Cb
> Thanks!
> --
> Fernando Gont
> e-mail: fernando@gont.com.ar || fgont@acm.org
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>
>
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

--0016367fb5f95324b804a6e4ccc1-- From fernando.gont.netbook.win@gmail.com Wed Jun 29 19:57:13 2011 Return-Path: X-Original-To: homegate@ietfa.amsl.com Delivered-To: homegate@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55ACE21F8677; Wed, 29 Jun 2011 19:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[AWL=1.077, 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 GjzgCHWLdLSt; Wed, 29 Jun 2011 19:57:12 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6150221F8672; Wed, 29 Jun 2011 19:57:12 -0700 (PDT) Received: by ywp31 with SMTP id 31so925618ywp.31 for ; Wed, 29 Jun 2011 19:57:11 -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=ytvjpVPzRjP+aUb6TcSbdH4abJe2RW2gdnDAzWcbHm4=; b=lyESNxbokgqwgDU6rv2G9Qk55TMB5NmeeLwWXDsEgEEyFTcnLC6ck8QHNqVJayYj1k RxhxLI6v8IRNPGU9ujr2vx3cIopTWuv0vaRPmFbqVJmrJgnh/7JLFzDNRww9JUYeSQ49 ZlNThhxbcCvcGCmaMcqRsvHW7lnmqvk4bbtfs= Received: by 10.91.119.8 with SMTP id w8mr1386584agm.12.1309402631812; Wed, 29 Jun 2011 19:57:11 -0700 (PDT) Received: from [192.168.123.103] ([190.48.223.58]) by mx.google.com with ESMTPS id g2sm1611058ano.14.2011.06.29.19.57.06 (version=SSLv3 cipher=OTHER); Wed, 29 Jun 2011 19:57:10 -0700 (PDT) Sender: Fernando Gont Message-ID: <4E0BE5FF.3000409@gont.com.ar> Date: Wed, 29 Jun 2011 23:57:03 -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: Cameron Byrne References: <4E0AE696.4020603@piuha.net> <4E0BDCF3.1090003@gont.com.ar> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 29 Jun 2011 20:39:36 -0700 Cc: IETF Discussion , "homegate@ietf.org" Subject: Re: [homegate] HOMENET working group proposal X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Broadband Home Gateway Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 02:57:13 -0000 On 06/29/2011 11:38 PM, Cameron Byrne wrote: > The opportunity for restoring e2e is one of the great opportunities of > ipv6 This assumes that e2e reachability is a desired property for all networks. > and it is my hope this new WG will drive that with facts and take > on fud. Wasn't the simple/advanced security RFCs produced by v6ops aimed at typical home devices? 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 Wed Jun 29 20:21:13 2011 Return-Path: X-Original-To: homegate@ietfa.amsl.com Delivered-To: homegate@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71E0011E80C1; Wed, 29 Jun 2011 20:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 3Hdyl+I-CThn; Wed, 29 Jun 2011 20:21:11 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 19D3C11E8083; Wed, 29 Jun 2011 20:21:11 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.messagingengine.com (Postfix) with ESMTP id 88C0121172; Wed, 29 Jun 2011 23:21:10 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute6.internal (MEProxy); Wed, 29 Jun 2011 23:21:10 -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:message-id:references:to; s=smtpout; bh=CMm5QgOwpRKcotVtmrAMByvzWDA=; b=UyUyAgNcUOe/x76GjQz5mpBqaSdptXHqOrxFIB9jv641W6PtB2xiXCiJiMpFlpHWa9nnPXLLRpDwXxotLphG0pUf+DcfkQBbVvUrPAjO8iNZXdO5NlV0O2KCMYFYyBLmoDXTykrhTttjbI3OMs5NrRCZMROiyMVv7ZFYggSUCNc= X-Sasl-enc: mKFHnhiEt5T2IaClvw26X3FD5SBl2rX9hv0DW/p/w6HV 1309404070 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 677DB400F0A; Wed, 29 Jun 2011 23:21:09 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-90-384369889 From: Keith Moore In-Reply-To: Date: Wed, 29 Jun 2011 23:20:51 -0400 Message-Id: <3C67E327-1147-46A6-92C5-C52851BC1BC0@network-heretics.com> References: <4E0AE696.4020603@piuha.net> <4E0BDCF3.1090003@gont.com.ar> To: Cameron Byrne X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Wed, 29 Jun 2011 20:39:36 -0700 Cc: Fernando Gont , "homegate@ietf.org" , IETF Discussion Subject: Re: [homegate] HOMENET working group proposal X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Broadband Home Gateway Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 03:21:13 -0000 --Apple-Mail-90-384369889 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 29, 2011, at 10:38 PM, Cameron Byrne wrote: > The utility of network based spi firewalls is debatable. Likely a = never ending debate. >=20 +1 --Apple-Mail-90-384369889 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On Jun 29, 2011, at 10:38 PM, Cameron Byrne wrote:

The utility of network based spi firewalls is debatable. Likely a never ending debate.

+1

--Apple-Mail-90-384369889-- From dwhite@olp.net Wed Jun 29 22:11:35 2011 Return-Path: X-Original-To: homegate@ietfa.amsl.com Delivered-To: homegate@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73D9B11E80C8; Wed, 29 Jun 2011 22:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 oUVqLjCz6Yxo; Wed, 29 Jun 2011 22:11:35 -0700 (PDT) Received: from pinky.olp.net (pinky2.olp.net [67.217.151.213]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6F811E8127; Wed, 29 Jun 2011 22:11:27 -0700 (PDT) Received: from quark.olp.net (olp-67-217-144-186.olp.net [67.217.144.186]) by pinky.olp.net (Postfix) with ESMTP id 2304229301A; Thu, 30 Jun 2011 00:11:24 -0500 (CDT) Received: by quark.olp.net (Postfix, from userid 1000) id D112C7B208F; Thu, 30 Jun 2011 00:11:23 -0500 (CDT) Date: Thu, 30 Jun 2011 00:11:23 -0500 From: Dan White To: Fernando Gont Message-ID: <20110630051123.GD4013@dan.olp.net> References: <4E0AE696.4020603@piuha.net> <4E0BDCF3.1090003@gont.com.ar> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4E0BDCF3.1090003@gont.com.ar> X-OS: Linux quark 2.6.39-1-amd64 x86_64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "homegate@ietf.org" , IETF Discussion Subject: Re: [homegate] HOMENET working group proposal X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Broadband Home Gateway Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 05:11:35 -0000 On 29/06/11 23:18 -0300, Fernando Gont wrote: >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 I'll add a 3rd component, which is application protocol mangling. What's given NAT a particularly bad name in recent years are the consistently poor SIP ALG implementations in many home routers, along with IPSEC ALGs, and other ALGs that attempt to fix the problem in the wrong way. End-to-end communication might be better approached as the desire to default to a configuration in which ALGs are no longer necessary, and then address firewalling separately, which could just as well default to a no inbound connection policy. >> 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. Home networks are bound to grow complex quite quickly. There's certainly value in using a model that residential users are familiar with, but it should be balanced by the inevitable need to address complexity that will outgrow the ability of many users to manage. A typically complex home network in the near future might be: alarm systems, utility and environmental monitoring, lifeline SIP service (911), Super Bowl broadcasts, etc., all connected via one home gateway device, which may have several outsourced/managed devices installed behind it. Having a simpler demarcation-like gateway device, which defers a lot of that complexity to other components in the network (such as end-to-end security), should go a long way in providing a sustainable model. -- Dan White From swmike@swm.pp.se Wed Jun 29 22:12:21 2011 Return-Path: X-Original-To: homegate@ietfa.amsl.com Delivered-To: homegate@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4DE911E80C8; Wed, 29 Jun 2011 22:12:21 -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 4hpLWTbUTFH6; Wed, 29 Jun 2011 22:12:21 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id BC12911E8128; Wed, 29 Jun 2011 22:12:20 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 5E7509C; Thu, 30 Jun 2011 07:12:18 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 5B39D9A; Thu, 30 Jun 2011 07:12:18 +0200 (CEST) Date: Thu, 30 Jun 2011 07:12:18 +0200 (CEST) From: Mikael Abrahamsson To: Fernando Gont In-Reply-To: <4E0BDCF3.1090003@gont.com.ar> Message-ID: References: <4E0AE696.4020603@piuha.net> <4E0BDCF3.1090003@gont.com.ar> 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" , IETF Discussion Subject: Re: [homegate] HOMENET working group proposal X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Broadband Home Gateway Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 05:12:22 -0000 On Wed, 29 Jun 2011, Fernando Gont 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. A more routed home instead of pure L2 one. > 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 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. I think this will also change, but not for all devices from all of the Internet. Still, I believe there is a place for a working group to look at this. I have subscribed already. -- Mikael Abrahamsson email: swmike@swm.pp.se From fernando.gont.netbook.win@gmail.com Wed Jun 29 23:51:58 2011 Return-Path: X-Original-To: homegate@ietfa.amsl.com Delivered-To: homegate@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1440D11E8144; Wed, 29 Jun 2011 23:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.04 X-Spam-Level: X-Spam-Status: No, score=-3.04 tagged_above=-999 required=5 tests=[AWL=0.559, 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 CJFwMd-Gqvcr; Wed, 29 Jun 2011 23:51:57 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 129C311E813B; Wed, 29 Jun 2011 23:51:57 -0700 (PDT) Received: by ywp31 with SMTP id 31so984661ywp.31 for ; Wed, 29 Jun 2011 23:51:56 -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=/0R3YYGmnJ6Lyflfku3ISMCbOSDFXOXl9MZ4HOpp3WU=; b=xADfpU0trLhwnwW5kVQoQ+rTN/eaStuQpFgMfEm4pmfQRNbN2WdfNmYLddJy2e9R2Q V86/HOgP03jOfXzBvhT3RjPLkuNXLnzMpgs6dCyTKm8sh6nGCZ39VfyrshCEp0rucNQM G5zjyenb7T3I6irYs9DFuKq6LPY3cl/g82PPA= Received: by 10.91.149.5 with SMTP id b5mr1511370ago.91.1309416716566; Wed, 29 Jun 2011 23:51:56 -0700 (PDT) Received: from [192.168.123.103] ([190.48.246.1]) by mx.google.com with ESMTPS id v9sm1752067anv.4.2011.06.29.23.51.49 (version=SSLv3 cipher=OTHER); Wed, 29 Jun 2011 23:51:55 -0700 (PDT) Sender: Fernando Gont Message-ID: <4E0C1CF8.7090601@gont.com.ar> Date: Thu, 30 Jun 2011 03:51:36 -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: Mikael Abrahamsson References: <4E0AE696.4020603@piuha.net> <4E0BDCF3.1090003@gont.com.ar> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "homegate@ietf.org" , IETF Discussion Subject: Re: [homegate] HOMENET working group proposal X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Broadband Home Gateway Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 06:51:58 -0000 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, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From swmike@swm.pp.se Thu Jun 30 00:26:02 2011 Return-Path: X-Original-To: homegate@ietfa.amsl.com Delivered-To: homegate@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3EA21F862E; Thu, 30 Jun 2011 00:26:02 -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 xuF8YGmGH2vU; Thu, 30 Jun 2011 00:26:01 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 9F77E21F85AF; Thu, 30 Jun 2011 00:25:32 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 9BCFF9C; Thu, 30 Jun 2011 09:25:29 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 99AEC9A; Thu, 30 Jun 2011 09:25:29 +0200 (CEST) Date: Thu, 30 Jun 2011 09:25:29 +0200 (CEST) From: Mikael Abrahamsson To: Fernando Gont In-Reply-To: <4E0C1CF8.7090601@gont.com.ar> Message-ID: References: <4E0AE696.4020603@piuha.net> <4E0BDCF3.1090003@gont.com.ar> <4E0C1CF8.7090601@gont.com.ar> 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" , IETF Discussion Subject: Re: [homegate] HOMENET working group proposal X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Broadband Home Gateway Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 07:26:02 -0000 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 From mark@townsley.net Thu Jun 30 02:57:12 2011 Return-Path: X-Original-To: homegate@ietfa.amsl.com Delivered-To: homegate@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: [homegate] HOMENET working group proposal X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Broadband Home Gateway Discussion 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 fernando.gont.netbook.win@gmail.com Thu Jun 30 03:40:25 2011 Return-Path: X-Original-To: homegate@ietfa.amsl.com Delivered-To: homegate@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: [homegate] HOMENET working group proposal X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Broadband Home Gateway Discussion 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 erik.taraldsen@telenor.com Thu Jun 30 06:51:36 2011 Return-Path: X-Original-To: homegate@ietfa.amsl.com Delivered-To: homegate@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E730811E8071; Thu, 30 Jun 2011 06:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311] 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 7ww3vXRkces1; Thu, 30 Jun 2011 06:51:36 -0700 (PDT) Received: from sv04.e.nsc.no (vip1scan.telenor.net [148.123.15.75]) by ietfa.amsl.com (Postfix) with ESMTP id 2A99A21F85AD; Thu, 30 Jun 2011 06:51:35 -0700 (PDT) Received: from tns-fbu-22-248.corp.telenor.no ([134.47.162.18] [134.47.162.18]) by sv04.nsc.no with ESMTPS id BT-MMP-729675; Thu, 30 Jun 2011 15:51:33 +0200 Received: from TNS-FBU-2E-016.corp.telenor.no ([134.47.163.219]) by tns-fbu-22-248.corp.telenor.no ([134.47.162.18]) with mapi; Thu, 30 Jun 2011 15:51:32 +0200 From: To: , Date: Thu, 30 Jun 2011 15:51:30 +0200 Thread-Topic: [homegate] HOMENET working group proposal Thread-Index: Acw25FkjU7sz+zclSF65n2H2+JtplAAR9c+Q Message-ID: <6A141C5EC2D26E47B3128814D5F69592156010B7D9@TNS-FBU-2E-016.corp.telenor.no> References: <4E0AE696.4020603@piuha.net> <4E0BDCF3.1090003@gont.com.ar> In-Reply-To: Accept-Language: nb-NO Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nb-NO Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: homegate@ietf.org, ietf@ietf.org Subject: Re: [homegate] HOMENET working group proposal X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Broadband Home Gateway Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 13:51:37 -0000 -----Original Message----- From: homegate-bounces@ietf.org [mailto:homegate-bounces@ietf.org] On Behal= f Of Mikael Abrahamsson Sent: 30. juni 2011 07:12 To: Fernando Gont Cc: homegate@ietf.org; IETF Discussion Subject: Re: [homegate] HOMENET working group proposal On Wed, 29 Jun 2011, Fernando Gont wrote: > This is exactly why the whole "system" needs to work, including uPNP like= =20 > functionality for nodes to talk to the firewall(s). UPnP like can indeed be UPnP. The UPnP Forum has defined IPv6 firewall con= trol as a part of UPnP now. http://upnp.org/specs/gw/UPnP-gw-WANIPv6FirewallControl-v1-Service.pdf Telenor, which I work for, is going to ask for this as a part of the IPv6 o= ffering from our CPE vendors. -Erik Taraldsen From jason.weil@twcable.com Thu Jun 30 07:14:46 2011 Return-Path: X-Original-To: homegate@ietfa.amsl.com Delivered-To: homegate@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 X-Mailman-Approved-At: Thu, 30 Jun 2011 07:27:36 -0700 Subject: Re: [homegate] [fun] status of the homenet effort X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Broadband Home Gateway Discussion 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: homegate@ietfa.amsl.com Delivered-To: homegate@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: [homegate] HOMENET working group proposal X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Broadband Home Gateway Discussion 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 palm@broadcom.com Thu Jun 30 07:56:27 2011 Return-Path: X-Original-To: homegate@ietfa.amsl.com Delivered-To: homegate@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: [homegate] HOMENET working group proposal X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Broadband Home Gateway Discussion 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: homegate@ietfa.amsl.com Delivered-To: homegate@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1DD11E80FB 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 LuOEQ8SzDJ6P for ; Thu, 30 Jun 2011 08:02:10 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8099A11E8083 for ; Thu, 30 Jun 2011 08:02:10 -0700 (PDT) Received: from kpbe19.cbf.corp.google.com (kpbe19.cbf.corp.google.com [172.25.105.83]) by smtp-out.google.com with ESMTP id p5UF29jd031712 for ; Thu, 30 Jun 2011 08:02:09 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1309446129; bh=RExe1DDgQkceelfgQ3zp/E4YQrE=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=MNL3aLrIl2Vg2iWz9ScIuK/SuTjTL/yobDK52Vw6GauO9ge4cLj/R9cB3pJ+MVkI8 kx2c5XZT4lyfsvs4qHW7Q== 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 pzk27 (pzk27.prod.google.com [10.243.19.155]) by kpbe19.cbf.corp.google.com with ESMTP id p5UF0oPJ025071 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 30 Jun 2011 08:02:08 -0700 Received: by pzk27 with SMTP id 27so2972442pzk.27 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 X-Mailman-Approved-At: Thu, 30 Jun 2011 08:05:24 -0700 Cc: "fun@ietf.org" , "homegate@ietf.org" Subject: Re: [homegate] [fun] status of the homenet effort X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Broadband Home Gateway Discussion 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: homegate@ietfa.amsl.com Delivered-To: homegate@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 X-Mailman-Approved-At: Thu, 30 Jun 2011 08:07:22 -0700 Subject: Re: [homegate] [fun] HOMENET working group proposal X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Broadband Home Gateway Discussion 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: homegate@ietfa.amsl.com Delivered-To: homegate@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: [homegate] [fun] HOMENET working group proposal X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Broadband Home Gateway Discussion 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: homegate@ietfa.amsl.com Delivered-To: homegate@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: [homegate] HOMENET working group proposal X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Broadband Home Gateway Discussion 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 fernando.gont.netbook.win@gmail.com Thu Jun 30 08:59:26 2011 Return-Path: X-Original-To: homegate@ietfa.amsl.com Delivered-To: homegate@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: [homegate] [fun] HOMENET working group proposal X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Broadband Home Gateway Discussion 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 08:46:50 2011 Return-Path: X-Original-To: homegate@ietfa.amsl.com Delivered-To: homegate@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) X-Mailman-Approved-At: Thu, 30 Jun 2011 09:16:24 -0700 Cc: fun@ietf.org, homegate@ietf.org, IETF Discussion Subject: Re: [homegate] HOMENET working group proposal X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Broadband Home Gateway Discussion 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 moore@network-heretics.com Thu Jun 30 09:05:46 2011 Return-Path: X-Original-To: homegate@ietfa.amsl.com Delivered-To: homegate@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) X-Mailman-Approved-At: Thu, 30 Jun 2011 09:16:25 -0700 Cc: IETF Discussion , fun@ietf.org, homegate@ietf.org Subject: Re: [homegate] [fun] HOMENET working group proposal X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Broadband Home Gateway Discussion 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 mark@townsley.net Thu Jun 30 09:34:16 2011 Return-Path: X-Original-To: homegate@ietfa.amsl.com Delivered-To: homegate@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: [homegate] HOMENET working group proposal X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Broadband Home Gateway Discussion 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: homegate@ietfa.amsl.com Delivered-To: homegate@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: [homegate] [fun] status of the homenet effort X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Broadband Home Gateway Discussion 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 jhw@apple.com Thu Jun 30 16:51:31 2011 Return-Path: X-Original-To: homegate@ietfa.amsl.com Delivered-To: homegate@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: [homegate] [fun] HOMENET working group proposal X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Broadband Home Gateway Discussion 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 martyf@gmail.com Thu Jun 30 18:34:45 2011 Return-Path: X-Original-To: homegate@ietfa.amsl.com Delivered-To: homegate@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D25A11E81D6; Thu, 30 Jun 2011 18:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBAxyWyqpwwC; Thu, 30 Jun 2011 18:34:44 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF1111E810B; Thu, 30 Jun 2011 18:34:44 -0700 (PDT) Received: by bwb17 with SMTP id 17so2687770bwb.31 for ; Thu, 30 Jun 2011 18:34:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:from:in-reply-to:mime-version:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=Cw2sj0iBy1I9ZPefltxqW9BDDjpqHGlALkVYeVg8XRo=; b=LE0JtNL4Dc81th6rzAZhfC9dDIMGjX79khL+p8cT5lv40CjyD12/v7+AZ4Q0xglE9t dO+li4VJpm9iNUndVWlon+yukdXWK+FQB2vUUb12SC/GlCe0SjrcvksU3i3V6Ku/77ry NJrs5R/JTBUu6lq9aDE9JC85M7pCrcVGXNKiw= Received: by 10.204.7.194 with SMTP id e2mr2448875bke.134.1309484035817; Thu, 30 Jun 2011 18:33:55 -0700 (PDT) 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> From: Martin Focazio In-Reply-To: Mime-Version: 1.0 (iPad Mail 8G4) Date: Thu, 30 Jun 2011 21:34:10 -0400 Message-ID: <-4529087406481929693@unknownmsgid> To: james woodyatt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "fun@ietf.org" , "homegate@ietf.org" Subject: Re: [homegate] [fun] HOMENET working group proposal X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Broadband Home Gateway Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 01:34:45 -0000 On Jun 30, 2011, at 19:51, james woodyatt wrote: > > 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 mob= ile service providers that don't have enough IPv4 addresses to serve all th= eir customers are in a bind and can't budge. The wireline service provider= s who have 5-10 years of IPv4 addresses in reserve are the ones whistling p= ast the graveyard. > 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. From moore@network-heretics.com Thu Jun 30 09:36:58 2011 Return-Path: X-Original-To: homegate@ietfa.amsl.com Delivered-To: homegate@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) X-Mailman-Approved-At: Thu, 30 Jun 2011 21:40:47 -0700 Cc: IETF Discussion , fun@ietf.org, homegate@ietf.org Subject: Re: [homegate] HOMENET working group proposal X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Broadband Home Gateway Discussion 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 robert@raszuk.net Thu Jun 30 16:11:00 2011 Return-Path: X-Original-To: homegate@ietfa.amsl.com Delivered-To: homegate@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 X-Mailman-Approved-At: Thu, 30 Jun 2011 21:40:47 -0700 Subject: Re: [homegate] [fun] HOMENET working group proposal X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Broadband Home Gateway Discussion 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 swmike@swm.pp.se Thu Jun 30 22:23:51 2011 Return-Path: X-Original-To: homegate@ietfa.amsl.com Delivered-To: homegate@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: [homegate] [fun] HOMENET working group proposal X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Broadband Home Gateway Discussion 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