Re: [homegate] [fun] status of the homenet effort
Mark Townsley <mark@townsley.net> Thu, 30 June 2011 16:36 UTC
Return-Path: <mark@townsley.net>
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 <multiple recipients>; 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 <mark@townsley.net>
In-Reply-To: <CA31F3ED.4AB6%jason.weil@twcable.com>
Date: Thu, 30 Jun 2011 18:36:02 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <7D900BF0-EA18-4ADA-A447-A9D3A717B61C@townsley.net>
References: <CA31F3ED.4AB6%jason.weil@twcable.com>
To: "Weil, Jason" <jason.weil@twcable.com>
X-Mailer: Apple Mail (2.1084)
Cc: "fun@ietf.org" <fun@ietf.org>, "homegate@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 <homegate.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homegate>, <mailto:homegate-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/homegate>
List-Post: <mailto:homegate@ietf.org>
List-Help: <mailto:homegate-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homegate>, <mailto:homegate-request@ietf.org?subject=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, > > 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" <mark@townsley.net> 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 <rdroms.ietf@gmail.com> >>> Jari Arkko <jari.arkko@piuha.net> >>> >>> Internet Area Advisor: >>> Jari Arkko <jari.arkko@piuha.net> >>> >>> 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 >>> >>> _______________________________________________ >>> 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 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.
- Re: [homegate] [fun] status of the homenet effort Mark Townsley
- Re: [homegate] [fun] status of the homenet effort Weil, Jason
- Re: [homegate] [fun] status of the homenet effort Erik Kline
- Re: [homegate] [fun] status of the homenet effort Mark Townsley
- Re: [homegate] [fun] status of the homenet effort Mark Townsley
- Re: [homegate] [fun] status of the homenet effort JP Vasseur (jvasseur)
- Re: [homegate] [fun] status of the homenet effort Weil, Jason
- Re: [homegate] [fun] status of the homenet effort Ralph Droms
- Re: [homegate] [fun] status of the homenet effort JP Vasseur (jvasseur)
- Re: [homegate] [fun] status of the homenet effort Weil, Jason
- Re: [homegate] [fun] status of the homenet effort Mark Townsley