[fun] new version of the charter

Jari Arkko <jari.arkko@piuha.net> Thu, 16 June 2011 05:16 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 D767B11E80BC for <fun@ietfa.amsl.com>; Wed, 15 Jun 2011 22:16:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.13
X-Spam-Level:
X-Spam-Status: No, score=-102.13 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SDXSvOWyQOxo for <fun@ietfa.amsl.com>; Wed, 15 Jun 2011 22:16:07 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 8514811E80B4 for <fun@ietf.org>; Wed, 15 Jun 2011 22:16:06 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id AF8672CC3B for <fun@ietf.org>; Thu, 16 Jun 2011 08:16:05 +0300 (EEST)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NyKCaeIF4Svk for <fun@ietf.org>; Thu, 16 Jun 2011 08:16:03 +0300 (EEST)
Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id B6FA72CC2F for <fun@ietf.org>; Thu, 16 Jun 2011 08:16:03 +0300 (EEST)
Message-ID: <4DF99193.3070305@piuha.net>
Date: Thu, 16 Jun 2011 08:16:03 +0300
From: Jari Arkko <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="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: [fun] new version of the charter
X-BeenThere: fun@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "FUture home Networking \(FUN\)" <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: Thu, 16 Jun 2011 05:16:08 -0000

Mark Townsley provided me with a suggested edit of the charter. I think 
it looks pretty good. Thoughts?

Home Networks (homenet)
-----------------------------------

Current Status: Proposed
Last Edit: Friday, June 16th, 2011

Chairs:
TBD

Internet Area Directors:
Ralph Droms <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 Link layer networking technology is poised to become more
heterogeneous, as networks begin to employ both traditional Ethernet
technology and link layers designed for low-powered sensor networks.

o Home networks are moving from a "one size fits all" model to
incorporation of dedicated segments for specific purposes. For
instance, a common feature in modern home routers in the ability to
support both guest and private network segments. Similar needs for
separation may occur in other cases, such as separating building
control or corporate extensions from the Internet access
network. Different segments may be associated with subnets that have
different routing and security policies.

o Service providers and are deploying IPv6, and support for IPv6 is
increasingly available in home gateway devices. While IPv6 resembles
IPv4 in many ways, it changes address allocation principles and allows
direct IP addressability and routing to devices in the home from the
Internet. This is a promising area in IPv6 that has proved challenging
in IPv4 with the proliferation of NAT.

o End-to-end communication is both an opportunity and a concern as it
enables new applications but also exposes nodes in the internal
networks to receipt of unwanted traffic from the Internet. Firewalls
that restrict incoming connections may be used to prevent exposure,
however, this reduces the efficacy of end-to-end connectivity that
IPv6 has the potential to restore.

Home networks need to provide the tools to handle these situations in
a manner accessible to all users of home networks. Manual
configuration is rarely, if at all, possible. The purpose of this
working group is to focus on this evolution, in particular as it
addresses the introduction of IPv6, by developing an architecture and
necessary additional tools addressing this full scope of requirements:

o prefix configuration for routers

o managing routing

o name resolution

o service discovery

o network security

Specifically, the group will produce an architecture document that
outlines how to construct home networks involving multiple routers and
subnets. This document is expected to apply the IPv6 addressing
architecture, prefix delegation, global and ULA addresses, source
address selection rules and other existing components of the IPv6
architecture.

In addition, the group will apply existing protocols to handle the
five requirements above. For prefix configuration, DHCPv6 PD is an
obvious candidate solution, possibly supplemented by some small
enhancements, such as new options. For automatic routing, it is
expected that existing routing protocols can be used as is, however, a
new mechanism may be needed in order to turn a selected protocol on by
default. For name resolution and service discovery, extensions are
needed to mDNS and DNS-SD to enable them to work across subnets.

For network security, the group shall document the concept of
"advanced security" as a further development of "simple security" from
RFC 6092. The main goal of this work is to enable a security policy
that adapts to IPv6 threats as they emerge, taking into account not
only traffic from the Internet at large, but within and leaving the
home network itself.

It is expected that the working group will define a set of protocol
specifications to accomplish the five requirements from
above. However, it is not in the scope of the working group to define
entirely new routing protocols or address allocation protocols. As
noted, additional options or other small extensions may be necessary
to use the existing protocols in these new configuration tasks. The
working group shall also not make any changes to IPv6 protocols or
addressing architecture. Prefix configuration, routing, and security
related work shall not cause any changes that are not backwards
compatible to existing IPv6 hosts. There may be host visible changes
in the work on naming and discovery protocols, however. In its design,
the working group shall also consider security aspects and the impact
on manageability. The main focus of the working group is home networks,
but the group's results may also find applications in other small
networks.

The working group will liaise with the relevant IETF working groups
and other standards bodies. In particular, the group should work
closely with the V6OPS working group, review any use or extension of
DHCP with the DHC working group, and get feedback on DNS issues from
the DNSEXT and DNSOP working groups. If it turns out that additional
options are needed for a routing protocol, they will be developed in
the appropriate Routing Area working group, with the HOMENET working
group providing the architecture and requirements for such
enhancements.

Milestones:

Oct 2011 First WG draft on the architecture
Dec 2011 First WG draft on prefix configuration
Dec 2011 First WG draft on routing
Jan 2011 First WG draft on name resolution
Feb 2011 First WG draft on service discovery
Feb 2011 First WG draft on perimeter security
Feb 2012 Submission of the architecture draft to the IESG as 
Informational RFC
Feb 2012 Start of routing related work in the relevant routing area 
working group, if needed
Mar 2012 Submission of the prefix configuration draft to the IESG as 
Standards Track RFC
Apr 2012 Submission of the routing draft to the IESG as Informational RFC
Jun 2012 Submission of the name resolution draft to the IESG as 
Standards Track RFC
Jun 2012 Submission of the service discovery draft to the IESG as 
Standards Track RFC
Aug 2012 Submission of the perimeter security draft to the IESG as 
Informational RFC