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

From: Soohong Daniel Park <[email-masked]>
Date: Fri, 1 Jul 2011 18:01:12 +0900

Presumably, the architrcture includes an analysis work considering the current home networking solutions, particulary DLNA. Correct? In fact, DLNA did the IPv6 over DLNA work before through a IPv6 Task Force, and came up with the whitepaper several years back. IPv6 is not well and widely embedded into DLNA yet though. Just curious how interop and harmonize between ietf work and DLNA. The past DLAN deliverable/efforts might be referred, and used for this Homenet work.

Daniel,

Soohong Daniel Park
Samsung Electronics, DMC R&D
www.soohongp.com, twitter:@natpt

2011. 7. 1. 오전 2:19 Jari Arkko <[email-masked]> 작성:

> 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:
> 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, 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:
> 
> 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 once 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/fun

---

From: Jari Arkko <[email-masked]>
Date: Fri, 01 Jul 2011 11:15:22 +0200

Daniel,
> Presumably, the architrcture includes an analysis work considering the current home networking solutions, particulary DLNA. Correct? In fact, DLNA did the IPv6 over DLNA work before through a IPv6…

Yes. There needs to be an awareness and analysis of everything that 
already exists -- DHCP components, V6OPS documents on simple security, 
DLNA work, UPnP work, etc.

Do you have a reference to the whitepaper and other associated 
information at DLNA?

Jari

---

From: Daniel Park <[email-masked]>
Date: Fri, 1 Jul 2011 18:31:09 +0900

Yes, since I was also a member of that TF within DLNA. But, I do not quite
sure now whether we can  share that whitepaper in ietf due to DLNA
membership policy.

Daniel

Soohong Daniel Park
from Galaxy S, twitter: @natpt
2011. 7. 1. 오후 6:15에 "Jari Arkko" <[email-masked]>님이 작성:
> Daniel,
>> Presumably, the architrcture includes an analysis work considering the
current home networking solutions, particulary DLNA. Correct? In fact, DLNA
did the IPv6 over DLNA work before through a IPv6 Task Force, and came up
with the whitepaper several years back. IPv6 is not well and widely embedded
into DLNA yet though. Just curious how interop and harmonize between ietf
work and DLNA. The past DLAN deliverable/efforts might be referred, and used
for this Homenet work.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 1 Jul 2011 12:19:59 +0200 (CEST)

On Fri, 1 Jul 2011, Daniel Park wrote:

> Yes, since I was also a member of that TF within DLNA. But, I do not 
> quite sure now whether we can share that whitepaper in ietf due to DLNA 
> membership policy.

Reading up on www.dlna.org it seems the way this organisation operates and 
envisions future development is incompatible with how the IETF operates?

<http://www.dlna.org/about_us/faqs/>

"The DLNA Guidelines are available to DLNA Member companies for free and 
to purchase for non-DLNA Members."

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Mark Townsley <[email-masked]>
Date: Fri, 1 Jul 2011 12:31:00 +0200

On Jul 1, 2011, at 12:19 PM, Mikael Abrahamsson wrote:

>> Yes, since I was also a member of that TF within DLNA. But, I do not quite sure now whether we can share that whitepaper in ietf due to DLNA membership policy.
> 
> Reading up on www.dlna.org it seems the way this organisation operates and envisions future development is incompatible with how the IETF operates?

While it is certainly easier to work with organizations that have more open policies, the IETF can and has managed to work with those that do not. For example, the BBF has liaised Working Texts to the v6ops and other WGs which are typically private to BBF members only, the IEEE has setup arrangements where IETF WG chairs can give access to password-protected document repositories to those that request it, etc. Also, the practical need for these kinds of arrangements depends on the overlap or lack thereof between IETF WG participants that do and do not have access via membership anyway. 

So, don't consider this a blocking function. We'll work it out, either ourselves or via the IAB (who officially manages SDO liaison relationships) if need be.

- Mark

> "The DLNA Guidelines are available to DLNA Member companies for free and to purchase for non-DLNA Members."
> 
> --

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 1 Jul 2011 18:24:18 -0600

I'm sure this is a spectacularly clueless question but, .... could someone say a bit more about why we need a routing protocol. I get that there is a need for small number of subnets, but it seems like most the requirements I have seen could be deal with using a single router that could route between all the subnets. As I said, clueless questions but can someone fill me in a bit on the use cases for a routing protocol? Or why a new routing protocol might be needed. Thanks. 

On Jun 29, 2011, at 2: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)
> Last Edit: Wednesday, June 29th, 2011
> 
> Chairs:
> TBD
> 
> Internet Area Directors:
> 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:
> 
> is expected to be within the scope of the working group one the

---

From: Jari Arkko <[email-masked]>
Date: Sat, 02 Jul 2011 10:01:41 +0200

Cullen,

Good question.

The charter does say that new routing protocols are NOT in scope, 
however. There may be a need to run a routing protocol, but if so, it 
would be an existing one.

But back to your question. Do we need a routing protocol, or can a 
single router be at the center and deal with all? I think the single 
router model is a good one even when there are multiple subnets. That 
being said, when you plug in. say,  the first sensor-network-to-WLAN 
router that can't do bridging you're in trouble. I personally think we 
should build for the case where there are multiple routers, while hoping 
that there is just one and that the number of subnets is either 1 or at 
least a very small number.

Jari

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 2 Jul 2011 11:19:58 +0200 (CEST)

> least a very small number.

It's my opinion that while it may not happen the first 5-10 years, any 
home will consist of multiple routers.

Any architecture we develop should in the long run handle multiple 
upstream providers (implying multiple provider CPEs) and multiple 
hierarchies of routers in the home. I also believe we need a routing 
protocol, plus a mechanism to do source based routing out to the correct 
ISP. Some of the needed mechanism might need to be developed in other WGs, 
but this WG can determine the need.

This was discussed in quite a lot of detail on v6ops a few months back for 
the CPE router requirement draft, I'm sure there are discussions in other 
WGs touching on these topics as well.

---

From: "JP Vasseur (jvasseur)" <[email-masked]>
Date: Sat, 2 Jul 2011 06:18:12 -0500

Agree with you Jari. Two notes:
1) You may have two routers connected to the Wan and still no need to run a routoing protocol
2) The only use case that I really for most apps is when nodes are not in direct reach

JP Vasseur
Cisco Fellow

Sent from Blackberry

----- Original Message -----
From: Jari Arkko [mailto:[email-masked]]
Sent: Saturday, July 02, 2011 03:01 AM
To: Cullen Jennings (fluffy)
Cc: [email-masked] <[email-masked]>
Subject: Re: [fun] Routing ?

Cullen,

Good question.

Jari

---

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Sat, 2 Jul 2011 07:30:55 -0400

On Jul 2, 2011, at 4:01 AM, "Jari Arkko" <[email-masked]> wrote:

> Cullen,
> 
> Good question.
> 
> The charter does say that new routing protocols are NOT in scope, however. There may be a need to run a routing protocol, but if so, it would be an existing one.
> 
> But back to your question. Do we need a routing protocol, or can a single router be at the center and deal with all? I think the single router model is a good one even when there are multiple subnets. That being said, when you plug in. say,  the first sensor-network-to-WLAN router that can't do bridging you're in trouble. I personally think we should build for the case where there are multiple routers, while hoping that there is just one and that the number of subnets is either 1 or at least a very small number.

ZigBee Alliance is developing it's specifications to accommodate exactly the use case Jari describes.  ZA anticipates a deployment scenario in which a Home Energy Controller (HEC) acts as a router (the technologies are unbridgeable) between the home network and an IEEE 802.15.4 subnet.

One router would be better, but we have this real and current use case for more than one, so we need to consider it.  Specific solutions have (of course) not been discussed; some architectures and use cases might not need a "routing protocol" at all to allow for multiple routers.

- Ralph

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 2 Jul 2011 06:31:51 -0600

Thanks - that makes sense.

---

From: Joel Jaeggli <[email-masked]>
Date: Sat, 2 Jul 2011 11:53:51 -0700

I would be really unconvinced that a new routing protocol would be required, for that to be the case there would need to be something greatly wrong wtih the existing options.

That said...

A rational for the existence of a routing protocol, involves the interconnection of existing addressing domains, and/or the cascading of devices... strictly hierarchical assignment can deal with the later, but to what extent does that always happen.

if you presuppose the existence of a god box to which everything else is connected the need for a routing protocol is greatly diminished or eliminated, that said, that presumption also applies to enterprise lans.

joel

---

From: Fred Baker <[email-masked]>
Date: Sat, 2 Jul 2011 20:29:45 -0700

On Jul 1, 2011, at 5:24 PM, Cullen Jennings wrote:

> I'm sure this is a spectacularly clueless question but, .... could someone say a bit more about why we need a routing protocol.

Well, if you draw a circle around the network so small that it consists of exactly one router (figure 2 of draft-baker-fun-multi-router), I guess we don't. However, I'll note that (discussion on v6ops a few months back) existing IPv4 residential gateways for the most part support a routing protocol - usually RIPv2. If present residential gateways have that requirement for market reasons, it does seem reasonable to expect future ones to.

I guess the question I would ask is not "why", but "given that there is evidently a present market requirement, why not". Can you explain to me why every residential gateway manufacturer save one - including Linksys - is wrong?

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 2 Jul 2011 23:54:07 -0600

>> I'm sure this is a spectacularly clueless question but, .... could someone say a bit more about why we need a routing protocol.

Jari's answer more or less convinced me on why the IETF was going to consider routing a good thing here. After I sent my questions, I saw your draft come out which provided even more info on use cases where routing would be needed.  

> I guess the question I would ask is not "why", but "given that there is evidently a present market requirement, why not". Can you explain to me why every residential gateway manufacturer save one -…

In the mid 90s it may have been a useful feature and some devices shipped it. I'd be willing to bet that one of the reasons that vendors ship it in new things today is because the other vendors have it on their data sheets. I will note that on the NATs I have used, it is not enabled by default. I'll doubt that RIPv2 is the best routing protocol for just about anything yet I don't hear people kicking down the doors at linksys asking for other routing protocols. There may be some set of people that use it - I don't know who they are - it's clearly not widely used. I don't think the fact RIPv2 is widely shipped convinces me one way or the other that routing is needed. I find the types of arguments in your draft more convincing to where it will be needed and where it will not. 

I tend to think that FUN should focus on home networks that have zero manual configuration with the exception of setting the wireless key (and I'd even like to see that simplified). Sure more complex things will be useful too but the small percentage of homes that need the use the complex thing will figure it out - its the ones that need the simple thing that are the problem. 

I'll note that more and more home stuff seems to be support VLANs for guest type access and other segregation. I also wonder if we will see more equipment that will detect if it is on the edge of the home network or in the middle. If it is on the edge, it might act more like a NAT or FW while if it is in the middle, it might act more like a bridge. In the v4 space, NATs that do this have significantly improved how well things that do broadcast based discovery work - like UPnP. I forget the stats but I think Elliot was telling me a substantial fraction of recent UDP port allocations were for broadcast based discovery protocols.