Subject: [fun] status of the homenet effort

From: Jari Arkko <[email-masked]>
Date: Wed, 29 Jun 2011 10:35:27 +0200

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 <[email-masked]>
Jari Arkko <[email-masked]>

Internet Area Advisor:
Jari Arkko <[email-masked]>

Routing Area Technical Advisor:
TBD

Security Area Technical Advisor:
TBD

Mailing Lists:
General Discussion: [email-masked]
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

---

From: Mark Townsley <[email-masked]>
Date: Wed, 29 Jun 2011 11:46:03 +0200

All,

Apologies for double-posting if there are folks that are subscribed to [email-masked] and [email-masked]. I'm hoping soon that someone will finally create [email-masked] 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).
> 
> Dec 2011 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
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/fun

---

From: "Weil, Jason" <[email-masked]>
Date: Thu, 30 Jun 2011 10:14:40 -0400

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" <[email-masked]> wrote:

>
>All,
>
>Apologies for double-posting if there are folks that are subscribed to
>[email-masked] and [email-masked]. I'm hoping soon that someone will
>finally create [email-masked] 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.
>
>> 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
>> within and among relatively small ³residential home² networks. For

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.

---

From: Erik Kline <[email-masked]>
Date: Thu, 30 Jun 2011 23:55:55 +0900

> with interoperability a possible casualty.

+1 to whatever can be done to get more industry implementors to IETF81
in a few weeks

---

From: Mark Townsley <[email-masked]>
Date: Thu, 30 Jun 2011 18:36:02 +0200

Thank you for the feedback, keep it coming.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 30 Jun 2011 19:19:05 +0200

This is just an update that the IESG approved the below charter for 
external review in its meeting today. "For external review" means that 
IETF participants and other people are formally asked to comment on it. 
The review period runs until July 14th.

Jari

Home Networks (homenet)

Current Status: Proposed
Last Edit: Wednesday, June 30th, 2011

Chairs:
TBD

Internet Area Directors:

Internet Area Advisor:

Mailing Lists:

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, as the necessary skills
and in some cases even suitable management interfaces are missing.

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:

is expected to be within the scope of the working group once the

Milestones: