[fun] proposed charter
Jari Arkko <jari.arkko@piuha.net> Tue, 07 June 2011 15:25 UTC
Return-Path: <jari.arkko@piuha.net>
X-Original-To: fun@ietfa.amsl.com
Delivered-To: fun@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE62011E810C for <fun@ietfa.amsl.com>; Tue, 7 Jun 2011 08:25:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.06
X-Spam-Level:
X-Spam-Status: No, score=-102.06 tagged_above=-999 required=5 tests=[AWL=-0.061, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJyT72smp24B for <fun@ietfa.amsl.com>; Tue, 7 Jun 2011 08:25:02 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 7DBED11E8152 for <fun@ietf.org>; Tue, 7 Jun 2011 08:24:41 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id A22432D366 for <fun@ietf.org>; Tue, 7 Jun 2011 18:24:38 +0300 (EEST)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NzykPLAnSEuO for <fun@ietf.org>; Tue, 7 Jun 2011 18:24:37 +0300 (EEST)
Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id DE3CF2D35A for <fun@ietf.org>; Tue, 7 Jun 2011 18:24:37 +0300 (EEST)
Message-ID: <4DEE42B5.7030000@piuha.net>
Date: Tue, 07 Jun 2011 18:24:37 +0300
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 2.0.0.24 (X11/20101027)
MIME-Version: 1.0
To: fun@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [fun] proposed charter
X-BeenThere: fun@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "FUture home Networking \(FUN\)" <fun.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/fun>, <mailto:fun-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/fun>
List-Post: <mailto:fun@ietf.org>
List-Help: <mailto:fun-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/fun>, <mailto:fun-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Jun 2011 15:25:03 -0000
FUture home Networks (FUN) ------------------------- Current Status: Proposed Last Edit: Friday, June 3rd, 2011 Chairs: TBD Internet Area Directors: Ralph Droms <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 in small networks such as those in homes. This evolution sets some requirements on IETF protocols. An obvious trend for home networking is the proliferation of networking technology in increasing number of different devices, from home entertainment systems to appliances and energy applications, just to name a few examples. This leads to a higher number of networked devices in each network. However, some more fundamental changes are occurring at the same time as well: o First, the link layer networking technology is become more heterogeneous, as networks are starting to employ, for instance, both traditional Ethernet technology and link layers designed for low-powered sensor networks. o Networks are also moving from a "one size fits all" model to dedicated segments for specific purposes. For instance, a common feature in high-end home routers in the ability to support both guest and private network segments. Similar needs for separation may occur in other cases, such as separating building control from the Internet access network. Typically, different subnets, routing and firewalls are used between the different segments. o Service providers are rolling out networks that support IPv6, and home gateway support for IPv6 is starting to appear. But for home networks, IPv6 is not just a new protocol, it also changes address allocation principles and allows end-to-end communication to the devices in the home. o End-to-end communication is both an opportunity and a problem, as it enables new applications but also exposes nodes in the internal networks to unwanted traffic from the Internet. Firewalls are in many cases needed to prevent exposure. However, this reduces the usefulness of end-to-end connectivity, as the firewall policy model is usually default deny, only allowing a small set of known protocols. In addition, consumer equipment typically reacts slowly if at all to changes in the typical Internet application, and it is likely that traffic for a popular application is not recognized by devices manufactured before that application was launched. Future home networks need to provide the tools to handle these situations in an easy manner. It is obvious that manual configuration is rarely possible. For IPv4, NAT and private address based solutions already provide limited solutions. The purpose of this working group is to develop an architecture and necessary additional tools for IPv6, to address the full scope of requirements: o prefix configuration for routers o managing routing (including turning it on by default) o name resolution o service discovery o perimeter security Specifically, the group should produce an architecture document that outlines how to construct home networks involving multiple routers and subnets. This document is expected to apply the IPv6 addressing architecture, prefix delegation, global and ULA addresses, source address selection rules and other existing components of the IPv6 architecture. In addition, the group will apply existing protocols to handle the five requirements above. For prefix configuration, DHCPv6 PD is an obvious candidate solution, possibly supplemented by some small enhancements, such as new options. For automatic routing, it is expected that existing routing protocols can be used as is, however, a new mechanism may be needed in order to turn a selected protocol on. For name resolution and service discovery, extensions are needed to mDNS and DNS-SD to enable them to work across subnets. For perimeter security, the group shall document the concept of "advanced security" as a further development of "simple security" from RFC 6092. The main goal of this work is to enable a default allow security policy. This may be accomplished, for instance, through driving security policy from an up-to-date database in the Internet or using simple security along with firewall control protocols such as PCP. It is expected that the working group defines a set of protocol specifications to accomplish the five requirements from above. However, it is NOT in the scope of the working group to define entirely new routing protocols or address allocation protocols. As noted additional options or other small extensions may be necessary to use the existing protocols in these new configuration tasks. The working group shall also not make any changes to IPv6 protocols or addressing architecture. Prefix configuration, routing, and security related work shall not cause any changes that are visible to hosts. There may be host visible changes in the work on naming and discovery protocols, however. In its design, the working group shall also consider security aspects and the impact on manageability. The working group will liaise with the relevant IETF working groups and other standards bodies. In particular, the group should work closely with the V6OPS working group, review any use or extension of DHCP with the DHC working group, and get feedback on DNS issues from the DNSEXT and DNSOP working groups. If it turns out that additional options are needed for a routing protocol, they will be developed in the appropriate Routing Area working group, with the FUN working group providing the architecture and requirements for such enhancements. Milestones: Oct 2011 First WG draft on the architecture Dec 2011 First WG draft on prefix configuration Dec 2011 First WG draft on routing Jan 2011 First WG draft on name resolution Feb 2011 First WG draft on service discovery Feb 2011 First WG draft on perimeter security Feb 2012 Submission of the architecture draft to the IESG as Informational RFC Feb 2012 Start of routing related work in the relevant routing area working group, if needed Mar 2012 Submission of the prefix configuration draft to the IESG as Standards Track RFC Apr 2012 Submission of the routing draft to the IESG as Informational RFC Jun 2012 Submission of the name resolution draft to the IESG as Standards Track RFC Jun 2012 Submission of the service discovery draft to the IESG as Standards Track RFC Aug 2012 Submission of the perimeter security draft to the IESG as Informational RFC
- [fun] proposed charter Jari Arkko