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

[Mark Townsley <[e-mail]>]

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" <[e-mail]> wrote:
> 
>> 
>> All,
>> 
>> Apologies for double-posting if there are folks that are subscribed to
>> [e-mail] and [e-mail]. I'm hoping soon that someone will
>> finally create [e-mail] 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 <[e-mail]>
>>> Jari Arkko <[e-mail]>
>>> 
>>> Internet Area Advisor:
>>> Jari Arkko <[e-mail]>
>>> 
>>> Routing Area Technical Advisor:
>>> TBD
>>> 
>>> Security Area Technical Advisor:
>>> TBD
>>> 
>>> Mailing Lists:
>>> General Discussion: [e-mail]
>>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/fun
>> 
>> _______________________________________________
>> fun mailing list
>> [e-mail]
>> 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.