Re: [homegate] [fun] status of the homenet effort

"Weil, Jason" <> Fri, 01 July 2011 13:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 03AF811E80FD; Fri, 1 Jul 2011 06:33:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.864
X-Spam-Status: No, score=0.864 tagged_above=-999 required=5 tests=[AWL=-1.026, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iggWFojARrgh; Fri, 1 Jul 2011 06:33:40 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id F3EB911E8127; Fri, 1 Jul 2011 06:32:27 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.65,458,1304308800"; d="scan'208";a="244804822"
Received: from unknown (HELO ([]) by with ESMTP/TLS/RC4-MD5; 01 Jul 2011 09:31:04 -0400
Received: from ([]) by ([]) with mapi; Fri, 1 Jul 2011 09:32:12 -0400
From: "Weil, Jason" <>
To: Mark Townsley <>, "JP Vasseur (jvasseur)" <>
Date: Fri, 1 Jul 2011 09:32:11 -0400
Thread-Topic: [fun] status of the homenet effort
Thread-Index: Acw380h/wVPhDWgST5W2OIltGtCygA==
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
acceptlanguage: en-US
Content-Type: text/plain; charset="euc-kr"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Mailman-Approved-At: Fri, 01 Jul 2011 07:02:54 -0700
Cc: "" <>, "" <>
Subject: Re: [homegate] [fun] status of the homenet effort
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 13:33:42 -0000

On 7/1/11 4:06 AM, "Mark Townsley" <>; wrote:

>On Jul 1, 2011, at 7:27 AM, JP Vasseur (jvasseur) wrote:
>> I also think that this deals with an important topic and the list of
>>items listed on the proposed charter are quite relevant. I'm just not
>>entirely clear on the "routing component": are you referring to:
>> * A requirement document for Routing in the home?
>At least a section within a home architecture document.
>> * A recommendation for a specific routing protocol ?

[JW] I see a guidelines/analysis for link-state vs. distance-vector
routing protocols in a multi-segment home network as being useful.

>> * A framework before the specification of a new routing protocol ?

[JW] A framework or justification statement for a new lightweight routing
protocol would be useful as well. A source/dest aware protocol has been
proposed as a possible solution for the multi-homed home network for

>The charter says:
>"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."
>- Mark
>> I'm clearly not expressing an opinion, just a question.
>> Thanks.
>> JP.
>> JP Vasseur
>> Cisco Fellow
>> Sent from Blackberry
>> ----- Original Message -----
>> From: Mark Townsley []
>> Sent: Thursday, June 30, 2011 11:36 AM
>> To: Weil, Jason <>;
>> Cc: <>;; <>;
>> Subject: Re: [fun] status of the homenet effort
>> 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
>>> 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
>>> relate firsthand that getting basic IPv6 functionality working in the
>>> 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
>>> 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
>>> 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
>>> with interoperability a possible casualty.
>>> FWIW, I would also add that the five topics in the charter are also
>>> 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
>>>> and I'm hoping soon that someone will
>>>> finally create and consolidate the membership
>>>> accordingly.
>>>> In the charter proposal below, I think you will see a lot of
>>>> with the consensus we achieved on the homegate list last year. Jari
>>>> taken that, feedback from the IESG, IAB, members of the
>>>> 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
>>>> 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
>>>> So, make no mistake, whether we end up as a WG or a BoF between now
>>>> 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
>>>> 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
>>>> 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
>>>>> 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
>>>>> 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
>>>>> 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
>>>>> early June. The proposal has been brought to the IESG, IAB and some
>>>>> directorates for discussion, and we've been going back and forth
>>>>> this is ready to become a working group or needs to be run as a BOF
>>>>> 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,
>>>>> and the IESG is positive, we will create the working group just in
>>>>> for the IETF. Otherwise, the slot reserved in the agenda for the
>>>>> 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
>>>>> 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:
>>>>> To Subscribe:
>>>>> Archive:
>>>>> 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
>>>>> direct IP addressability and routing to devices in the home from the
>>>>> Internet. This is a promising area in IPv6 that has proved
>>>>> 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
>>>>> 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
>>>>> 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
>>>>> that the group has to discuss some of the below solutions, however,
>>>>> 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,
>>>>> 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
>>>>> work across subnets.
>>>>> For network security, the group shall document the concept of
>>>>> "advanced security" as a further development of "simple security"
>>>>> 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
>>>>> 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 mailing list
>>> 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
>> _______________________________________________
>> fun mailing list

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.