Subject: HOMENET working group proposal

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

I would like to announce a new effort around home networking and solicit 
some feedback.

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. Go here to subscribe https://www.ietf.org/mailman/listinfo/fun 
and below you can find the most recent charter proposal. Please join the 
list and the discussion.

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). Note also that I'm sending this to the old homegate list, to 
inform people who were interested in that. I'd like the discussion to 
happen on the [email-masked] list, however.

Jari

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: Fernando Gont <[email-masked]>
Date: Wed, 29 Jun 2011 23:18:27 -0300

Hi, Jari,

My high level comment/question is: the proposed charter seems to stress
that IPv6 is the driver behind this potential wg effort... however, I
think that this deserves more discussion -- it's not clear to me why/how
typical IPv6 home networks would be much different from their IPv4
counterparts.

Bellow you'll find some comments/questions about the proposed charter.
They are not an argument against or in favour of the creation of the
aforementioned wg, but rather comments and/or requests for clarification...

On 06/29/2011 05:47 AM, Jari Arkko wrote:
[....]
> in IPv4 with the proliferation of NAT.

NAT devices involve two related but different issues:
* address translation
* an implicit "allow only return traffic" firewall-like functionality

One would hope/expect that the former will be gone with IPv6. However, I
don't think the latter will. As a result, even when you could "address"
nodes that belong to the "home network", you probably won't be able to
get your packets to them, unless those nodes initiated the communication
instance.

For instance (and of the top of my head), this functionality is even
proposed in the "simple security" requirements that had been produced by
v6ops.

> IPv6 has the potential to restore.

I personally consider this property of "end-to-end connectivity" as
"gone". -- among other reasons, because it would require a change of
mindset. I'm more of the idea that people will replicate the
architecture of their IPv4 networks with IPv6, in which end-systems are
not reachable from the public Internet.

Thanks!
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 29 Jun 2011 19:38:37 -0700

> not reachable from the public Internet.

The opportunity for restoring e2e is one of the great opportunities of ipv6
and it is my hope this new WG will drive that with facts and take on fud.

The utility of network based spi firewalls is debatable. Likely a never
ending debate.

Cb
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Fernando Gont <[email-masked]>
Date: Wed, 29 Jun 2011 23:57:03 -0300

> The opportunity for restoring e2e is one of the great opportunities of

This assumes that e2e reachability is a desired property for all networks.

> and it is my hope this new WG will drive that with facts and take

Wasn't the simple/advanced security RFCs produced by v6ops aimed at
typical home devices?

Thanks,

---

From: Keith Moore <[email-masked]>
Date: Wed, 29 Jun 2011 23:20:51 -0400

On Jun 29, 2011, at 10:38 PM, Cameron Byrne wrote:
> The utility of network based spi firewalls is debatable. Likely a never ending debate.
> 

+1

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 30 Jun 2011 12:56:03 +0900

Fernando Gont wrote:

> "gone".

How do you think about P2P applications?

							Masataka Ohta

PS

End to end connectivity of IPv4 can be maintained/restored by
PR-IP (port restricted IP) such as A+P, E2ENAT and PE-ARP.

---

From: Martin Rex <[email-masked]>
Date: Thu, 30 Jun 2011 06:25:30 +0200 (MEST)

> > I personally consider this property of "end-to-end connectivity" as

It's gone for good.

Didn't the internet start out as a Network of Network.
Then there was a time when it became popular to the general
public, and everyone was happy when he had one single PC
with a modem to connect to the internet.

Today we're back to where it started, the internet
is a network of (local) networks, and it is important
to keep the networks properly seperated because of the
unbounded growth of features and bugs/vulnerabilities
in popular operating systems for the computer novice.

The average DSL home route does more than just NAT,
it is a DHCP server vor a private address space,
a DNS server that fakes locally assigned/claimed hostnames
into the DNS name resolution (and continues to work even
if the internet link is down).  You really do not want
devices of everyones home network (e.g the admin web interface
of your DSL router, your NAS, your set-top-box, etc.
to becomme freely accessible from everywhere on the internet,
because it is likely close to impossible to preconfigure
new home&entertainment devices in a fashion that they're
securely accessible only to their rightful average
non-security-geek owners and nobody else, and it will
be entirely impossible to convert any of the existing
installed base of devices into such a fully-accessible-for-owner
and 100%-inaccessible-for-everybody-else configuration.

If IPv6 does not offer the the same properties as the
current IPv4 internet subscription for the average home user
-- which implies NAT, private local network and smooth
local operation when the internet is down -- then
very few will want IPv6 to their homes (I certainly
wouldn't want it), and IPv6 adoption will continue to
drag along for several years.

> How do you think about P2P applications?

NAT-PMP or IGD over UPnP come to mind.

-Martin

---

From: Keith Moore <[email-masked]>
Date: Thu, 30 Jun 2011 00:32:52 -0400

> drag along for several years.

In other words, you think the networks of the future should be every bit as dysfunctional as today's networks. 

I think we can all agree that (a) ordinary users are not security experts, and (b) practically all network protocol servers are vulnerable to attack.

However it does not follow that home networks need NAT or private address space.  Those are hacks of the 1990s.  They always were shortsighted, and they turned out to be an operational disaster.  We can do better.

Keith

---

From: Melinda Shore <[email-masked]>
Date: Wed, 29 Jun 2011 20:51:35 -0800

> However it does not follow that home networks need NAT or private address space.  Those are hacks of the 1990s.  They always were shortsighted, and they turned out to be an operational disaster.  W…

We can and should, but it's pretty clear that if the IETF
were good at evangelizing we wouldn't be in this situation
in the first place.  The focus really needs to be on producing
good, secure protocols that work on the networks we've got.

Melinda

---

From: Mark Andrews <[email-masked]>
Date: Thu, 30 Jun 2011 14:55:26 +1000

In message <[email-masked]>, Martin Rex writes
> > > I personally consider this property of "end-to-end connectivity" as

It doesn't have to be.
 
> in popular operating systems for the computer novice.

Very little of which a standalone firewall helps with.

> and 100%-inaccessible-for-everybody-else configuration.

Total utter garbage.  For IPv4 DHCP tells you what is local and
what isn't when the address is assigned.  For IPv6 you know from
the RA's what prefixes are local and what arn't.

About the only thing you want the external router/firewall to do
is to prevent spoofed traffic for internal addresses being delivered.
Everything else should be wide open by default and let the host
firewall deal with the rest.

Too many of us come from a time when machines didn't have firewalls
built into them and you needed a external firewall.  It has warped
our thinking about security.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Martin Rex <[email-masked]>
Date: Thu, 30 Jun 2011 07:09:45 +0200 (MEST)

Keith Moore wrote:
> 
> In other words, you think the networks of the future should be every
> bit as dysfunctional as today's networks. 

It is not dysfunctional just because it is slightly more complicated
to use that if everything was freely accessible to complete self-service.

> 
> I think we can all agree that (a) ordinary users are not security experts,

agreed

>
> and (b) practically all network protocol servers are vulnerable to attack.

Nope.  The risk is directly related to the complexity of the accessible
parts.

That is why I want the internet gateway to be a NAT, maybe even an IPv4 NAT.
I doesn't take that much to make the outwards facing parts of an IPv4 NAT
completely bug-free.

> 
> However it does not follow that home networks need NAT or private address
> space.  Those are hacks of the 1990s.  They always were shortsighted, and
> they turned out to be an operational disaster.  We can do better.

NAT and private address space for the home networks is as healthy to
the internet population as is water & soap to the health of mankind.

One may have to remind small kids regularly to wash their hands,
but of them grasp the concept and the benefits when they grow up.

-Martin

---

From: Keith Moore <[email-masked]>
Date: Thu, 30 Jun 2011 01:26:17 -0400

On Jun 30, 2011, at 1:09 AM, Martin Rex wrote:

(a bunch of stuff in defense of NAT)

Rather than having another of an endless series of discussions about the merits of NAT or lack thereof, can we just agree that it should not be pre-ordained that this WG should assume NAT as a solution?

Keith

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 30 Jun 2011 15:45:26 +0900

> NAT-PMP or IGD over UPnP come to mind.

P2P applications need seed peers with fixed addresses and ports.

						Masataka Ohta

---

From: Fernando Gont <[email-masked]>
Date: Thu, 30 Jun 2011 03:51:36 -0300

On 06/30/2011 02:12 AM, Mikael Abrahamsson wrote:
>> My high level comment/question is: the proposed charter seems to
>> stress that IPv6 is the driver behind this potential wg effort...
>> however, I think that this deserves more discussion -- it's not clear
>> to me why/how typical IPv6 home networks would be much different from
>> their IPv4 counterparts.
> 
> In my mind, I see the possibility of /56 PD enabling different subnets
> for different kinds of devices with different security and functional
> needs, and also chaining of L3 devices. This definitely warrants a group
> to look at that.

My point was that, except for the mechanism for PD, I don't see a
substantial difference here that would e.g. prevent this from being
developed for IPv4 (in addition to IPv6). -- Yes, I know we need to
deploy IPv6... but I don't think you can expect people to get rid of
their *working* IPv4 devices... (i.e., not sure why any of this
functionality should be v6-only)

>> One would hope/expect that the former will be gone with IPv6. However,
>> I don't think the latter will. As a result, even when you could
>> "address" nodes that belong to the "home network", you probably won't
>> be able to get your packets to them, unless those nodes initiated the
>> communication instance.
> 
> This is exactly why the whole "system" needs to work, including uPNP
> like functionality for nodes to talk to the firewall(s).

I think this deserves a problem statement that clearly describes what we
expect to be able to do (but currently can't), etc. And, if this is
meant to be v6-only, state why v4 is excluded -- unless we're happy to
have people connect their IPv4-devices, and see that they cannot
communicate anymore.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 30 Jun 2011 04:09:38 -0300

> How do you think about P2P applications?

I think about applications that would benefit from e2e connectivity, but
since it is gone, they have to spend quite a bit of effort to traverse
middleboxes such as NATs. -- the network is not dumb anymore.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 30 Jun 2011 04:24:58 -0300

On 06/30/2011 02:26 AM, Keith Moore wrote:
> Rather than having another of an endless series of discussions about
> the merits of NAT or lack thereof, can we just agree that it should
> not be pre-ordained that this WG should assume NAT as a solution?

I was originally arguing, at the very least, in favour of a stateful
firewall at the border.

Please correct me if I'm wrong, but this is what the IETF has already
proposed (output of v6ops) for v6.

I don't think you want your home network to be owned as a result of last
"patch Tuesday" set of vulnerabilities... or that you want a brittle
printer or fridge possibly impossible to patch) to be DoSed/owned just
because it was cool to have it available on the Internet. (nor should we
expect them to run a "host-based" firewall).

Many/most networks are there to provide a specific service to their
users (not for us to experiment with) -- whether we like it or not. As
long as they are able to provide that service, I don't find a compelling
reason for them to increase risk through unnecessary increased exposure.

(Yes, in those cases in which you *need* increased exposure, you open
your network -- i.e., "default deny")

Thanks,

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 30 Jun 2011 17:01:47 +0900

> middleboxes such as NATs. -- the network is not dumb anymore.

As I wrote, with PR-IP such as E2ENAT, the network can be dumb.

If several fixed port numbers are blocked, what's wrong if the
network is dumb?

Anyway, as it is a lot easier for applications to traverse NAT
than to support IPv6, you should better say IPv6 has never
arrived.

						Masataka Ohta

---

From: Jari Arkko <[email-masked]>
Date: Thu, 30 Jun 2011 11:31:57 +0200

Fernando,

First off, I'm switching the reply headers to [email-masked] now, deleting 
the old homegate list from this discussion.

Secondly, I would like to explain the motivation behind focusing this 
work on IPv6. Its not so much about IPv6 being different (though I hope 
it is in some respects). The reason why I want this working group to 
focus on IPv6 is that I don't think new IETF work would have much effect 
on IPv4 home network architecture. Whereas I think we have a good chance 
of having an effect in the IPv6 case, given that there is not much 
deployed base yet in home routers, consumer ISPs, etc.

Finally, I don't think we need to take a black-and-white approach to 
discussing the end-to-end model. Obviously we know about the V6OPS 
simple security work. Of course there are firewalls in IPv6, restricting 
incoming traffic. That being said, I think the right architecture for 
IPv6 home networks is that incoming traffic is restricted *by policy* on 
a per-need basis, not by an addressing design that forever prevents us 
from allowing specific incoming protocols. This is what we mean by 
architecture specification from this working group. Practical network 
design that does the right thing and lets people do what they want -- 
not a requirement to open your network up for anything.

Jari

Fernando Gont kirjoitti:
> that IPv6 is the driver behind this potential wg effort... however, Ie

---

From: Jari Arkko <[email-masked]>
Date: Thu, 30 Jun 2011 11:38:31 +0200

Fernando,

> functionality should be v6-only)

You have to separate IETF specifications and functionality of real-world 
products. Obviously everyone is going to have IPv4 based home networks 
for a long time.

But their architecture is largely done and cannot be easily affected. 
Vendors are now looking into adding IPv6 into their home routers and 
other devices. I want to be able to show them how to do it right. They 
can, of course, replicate everything exactly as in IPv4. Much of it is 
right, of course, but on some areas I think we can do better. This is 
why the working group should focus on IPv6. If the group is successful, 
IPv4 network design continues to be what it is, but our recommendations 
for the IPv6 network design are adopted by vendors' home devices.

Jari

---

From: Fernando Gont <[email-masked]>
Date: Thu, 30 Jun 2011 06:47:29 -0300

Jari,

On 06/30/2011 06:38 AM, Jari Arkko wrote:
> why the working group should focus on IPv6. 

My point is: Will implementation of the produced RFCs lead to home
networks in which stuff works for IPv6 differently from how it works for
IPv4? e.g., your home network would have multiple subnets (thanks to
PD), but a single IPv4 subnet?

If our work focuses only on IPv6, I get the impression that we're
heading in that direction.

If HOMENET is going to improve stuff that we already do with IPv4 (by
leveraging IPv6), then that's fine... but not what I read from this
discussion and the proposed charter.

Thoughts?

Thanks,

---

From: Jari Arkko <[email-masked]>
Date: Thu, 30 Jun 2011 12:02:53 +0200

Fernando,

> IPv4? 

That is the plan. And when I say "differently", I mean differences such as

* prefix delegation
* global addresses and firewalls instead of private addresses and NATs
* across-subnet communication internally in the home can be routed, not 
NATted

> e.g., your home network would have multiple subnets (thanks to

But the examples you cite are not differences we are really aiming at. 
Multiple subnets is something that generally should be avoided where 
possible, but cannot be completely avoided. It applies to IPv4 and IPv6 
in equal manner, e.g., when you have a Guest and Private SSIDs on your 
wireless. In this case the difference between IPv4 and IPv6 is merely 
that in one case we NAT to the Internet and between the two networks, in 
another case we route/firewall.

> discussion and the proposed charter.

My point is that I don't think we can change the IPv4 situation. We can 
affect the way IPv6 is used. Maybe we can even make things better in 
IPv6 than they were in IPv4. So in the end the user experience may 
improve for people who use IPv6, but it is definitely not our goal to 
improve IPv4.

Jari

---

From: Fernando Gont <[email-masked]>
Date: Thu, 30 Jun 2011 07:40:17 -0300

Hi, Mark (and Jari),

Thanks so much for your clarification! All my questions/comments have
been addressed.

Thanks,
Fernando

On 06/30/2011 06:57 AM, Mark Townsley wrote:
> 
> I think the consensus we had in the past BoFs and discussion in and
> around this topic can be summed up as stating that homenet
> deliverables will:
> 
> - coexist with (existing) IPv4 protocols, devices, applications,
> etc. - operate in a (future) IPv6-only home network in the absence of
> IPv4 - be IP-agnostic whenever possible
> 
> In other words, anything we do for the IPv6 homenet cannot actively
> break what's already running on IPv4. Also, trying to define what the
> IPv4 home network should be has long reached a point of diminishing
> returns given the effort in doing so coupled with our ability to
> significantly affect what's already deployed. There's still hope we
> can help direct IPv6, as such that is homenet's primary focus.
> However, when we can define something that is needed for IPv6 in a
> way that is also useful for IPv4 without making significant
> concessions, we should go ahead and do so.
> 
> - Mark
> 
> 
> 
> On Jun 30, 2011, at 9:25 AM, Mikael Abrahamsson wrote:
> 
>> On Thu, 30 Jun 2011, Fernando Gont wrote:
>> 
>>> substantial difference here that would e.g. prevent this from
>>> being developed for IPv4 (in addition to IPv6). -- Yes, I know we
>>> need to deploy IPv6... but I don't think you can expect people to
>>> get rid of their *working* IPv4 devices... (i.e., not sure why
>>> any of this functionality should be v6-only)
>> 
>> Chaining NAT boxes already work. I also feel that we shouldn't put
>> in a lot of work to develop IPv4 further, that focus should be put
>> on IPv6.
>> 
>>> I think this deserves a problem statement that clearly describes
>>> what we expect to be able to do (but currently can't), etc. And,
>>> if this is meant to be v6-only, state why v4 is excluded --
>>> unless we're happy to have people connect their IPv4-devices, and
>>> see that they cannot communicate anymore.
>> 
>> IPv4 should be excluded because it's a dead end, and we all know
>> it. We're just disagreeing when it's going to die and how.
>> 
>> -- Mikael Abrahamsson    email: [email-masked] 
>> _______________________________________________ homegate mailing
>> list [email-masked] 
>> https://www.ietf.org/mailman/listinfo/homegate
> 
> _______________________________________________ homegate mailing
> list [email-masked] 
> https://www.ietf.org/mailman/listinfo/homegate
>

---

From: Ralph Droms <[email-masked]>
Date: Thu, 30 Jun 2011 07:52:35 -0400

> good, secure protocols that work on the networks we've got.

...or the networks we can see coming in the near future.  ZigBee Alliance is driving an IPv6-based multi-link architecture through planned deployments of SE2.0 by several utilities.  BBF and CableLabs both expect IPv6, end-to-end connectivity 

Homenet will avoid breaking existing IPv4 deployments in the networks we've got today, but won't spend resources on unnecessary (in some cases impossible) feature parity.

- Ralph

---

From: Eric Burger <[email-masked]>
Date: Thu, 30 Jun 2011 07:58:20 -0400

Given the 5-year lead time to get a protocol suite done in the IETF, why would we start by looking backward?

---

From: Keith Moore <[email-masked]>
Date: Thu, 30 Jun 2011 08:16:53 -0400

> I was originally arguing, at the very least, in favour of a stateful

I don't think the WG should be bound by existing technologies and assumptions. 

Perimeter security of some kind is probably appropriate.  That doesn't mean that it has to look like firewalls do today.  For one thing, users shouldn't have to muck with the details of which ports to allow.  For another, trying to make security decisions be based on source IP address is ridiculous.  And the idea that every application server on a home network needs to negotiate access through some application-specific external server (as is generally the case with NATs today) is also ridiculous.

> proposed (output of v6ops) for v6.

For some strange reason, I'm not particularly impressed with the output of v6ops lately.  Especially in their ability to consider the interests of the broader Internet.

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 30 Jun 2011 08:21:43 -0400

> networks in which stuff works for IPv6 differently from how it works for

hopefully!

> PD), but a single IPv4 subnet?

for that specific example, not clear.   my impression is that the architecture of home networks should work regardless of whether there's a single subnet or multiple subnets.

> heading in that direction.

nothing says that some results of the work can't also apply to IPv4.  but people are far too mired in outdated assumptions today, such as the idea that every network needs a NAT or a firewall that filters based on IP addresses and ports.

> leveraging IPv6), then that's fine... 

no, that's not fine.   that's painting ourselves (and the Internet) into a corner.

Keith

---

From: Fernando Gont <[email-masked]>
Date: Thu, 30 Jun 2011 09:50:02 -0300

On 06/30/2011 09:21 AM, Keith Moore wrote:

> nothing says that some results of the work can't also apply to IPv4.
> but people are far too mired in outdated assumptions today, such as
> the idea that every network needs a NAT or a firewall that filters
> based on IP addresses and ports.

I did not even argue about ports or addressing, but rather about who
initiated the communication instance.

>> If HOMENET is going to improve stuff that we already do with IPv4
>> (by leveraging IPv6), then that's fine...
> 

I was mostly referring to not breaking what already works with v4 (i.e.,
not be a MUST for all devices in a home network to support some v6
feature for the network to work, such that our existing v4-only devices
can co-exist in whatever v6 home-network architecture we envision).

Thanks,

---

From: Dan White <[email-masked]>
Date: Thu, 30 Jun 2011 00:11:23 -0500

>* an implicit "allow only return traffic" firewall-like functionality

I'll add a 3rd component, which is application protocol mangling.

What's given NAT a particularly bad name in recent years are the
consistently poor SIP ALG implementations in many home routers, along with
IPSEC ALGs, and other ALGs that attempt to fix the problem in the wrong
way.

End-to-end communication might be better approached as the desire to
default to a configuration in which ALGs are no longer necessary, and then
address firewalling separately, which could just as well default to a no
inbound connection policy.

>not reachable from the public Internet.

Home networks are bound to grow complex quite quickly. There's certainly
value in using a model that residential users are familiar with, but it
should be balanced by the inevitable need to address complexity that will
outgrow the ability of many users to manage.

A typically complex home network in the near future might be: alarm
systems, utility and environmental monitoring, lifeline SIP service (911),
Super Bowl broadcasts, etc., all connected via one home gateway device,
which may have several outsourced/managed devices installed behind it.

Having a simpler demarcation-like gateway device, which defers a lot of
that complexity to other components in the network (such as end-to-end
security), should go a long way in providing a sustainable model.

-- 
Dan White

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 30 Jun 2011 07:12:18 +0200 (CEST)

> typical IPv6 home networks would be much different from their IPv4 

In my mind, I see the possibility of /56 PD enabling different subnets for 
different kinds of devices with different security and functional needs, 
and also chaining of L3 devices. This definitely warrants a group to look 
at that.

A more routed home instead of pure L2 one.

> get your packets to them, unless those nodes initiated the communication 

This is exactly why the whole "system" needs to work, including uPNP like 
functionality for nodes to talk to the firewall(s).

> not reachable from the public Internet.

I think this will also change, but not for all devices from all of the 
Internet. Still, I believe there is a place for a working group to look at 
this.

I have subscribed already.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 30 Jun 2011 09:25:29 +0200 (CEST)

> functionality should be v6-only)

Chaining NAT boxes already work. I also feel that we shouldn't put in a 
lot of work to develop IPv4 further, that focus should be put on IPv6.

> have people connect their IPv4-devices, and see that they cannot 

IPv4 should be excluded because it's a dead end, and we all know it. We're 
just disagreeing when it's going to die and how.

---

From: Mark Townsley <[email-masked]>
Date: Thu, 30 Jun 2011 11:57:06 +0200

I think the consensus we had in the past BoFs and discussion in and around this topic can be summed up as stating that homenet deliverables will:

- coexist with (existing) IPv4 protocols, devices, applications, etc.
- operate in a (future) IPv6-only home network in the absence of IPv4
- be IP-agnostic whenever possible

In other words, anything we do for the IPv6 homenet cannot actively break what's already running on IPv4. Also, trying to define what the IPv4 home network should be has long reached a point of diminishing returns given the effort in doing so coupled with our ability to significantly affect what's already deployed. There's still hope we can help direct IPv6, as such that is homenet's primary focus.  However, when we can define something that is needed for IPv6 in a way that is also useful for IPv4 without making significant concessions, we should go ahead and do so. 

- Mark

On Jun 30, 2011, at 9:25 AM, Mikael Abrahamsson wrote:

>> My point was that, except for the mechanism for PD, I don't see a substantial difference here that would e.g. prevent this from being developed for IPv4 (in addition to IPv6). -- Yes, I know we need to deploy IPv6... but I don't think you can expect people to get rid of their *working* IPv4 devices... (i.e., not sure why any of this functionality should be v6-only)
> 
> Chaining NAT boxes already work. I also feel that we shouldn't put in a lot of work to develop IPv4 further, that focus should be put on IPv6.
> 
>> I think this deserves a problem statement that clearly describes what we expect to be able to do (but currently can't), etc. And, if this is meant to be v6-only, state why v4 is excluded -- unless we're happy to have people connect their IPv4-devices, and see that they cannot communicate anymore.
> 
> IPv4 should be excluded because it's a dead end, and we all know it. We're just disagreeing when it's going to die and how.
> 
> -- 
> homegate mailing list
> [email-masked]

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 30 Jun 2011 12:53:25 +0200

> * across-subnet communication internally in the home can be routed,
not

[Pascal] I'd add to that multiple virtual topologies, and heterogeneous
subnets where even the link layer is not consistent across the subnet.

Automation and command/control already uses wireless technologies that
are non WIFI; ISA100.15 already works on backhaul technologies; the IETF
is missing a clear model to explain them how we isolate flows and merge
heterogeneous links into one subnet. 

I think there is a lot this group can do to pursue / extend what was
done at 6LoWPAN (ND, backbone router) so that the work there connects to
the rest of the home, and by extension, the rest of other networks such
as building and industrial plants.

Cheers,

Pascal

---

From: <[email-masked]>
Date: Thu, 30 Jun 2011 15:51:30 +0200

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mikael Abrahamsson
Sent: 30. juni 2011 07:12
To: Fernando Gont
Cc: [email-masked]; IETF Discussion
Subject: Re: [homegate] HOMENET working group proposal

> functionality for nodes to talk to the firewall(s).

UPnP like can indeed be UPnP.  The UPnP Forum has defined IPv6 firewall control as a part of UPnP now.
http://upnp.org/specs/gw/UPnP-gw-WANIPv6FirewallControl-v1-Service.pdf

Telenor, which I work for, is going to ask for this as a part of the IPv6 offering from our CPE vendors.

-Erik Taraldsen

---

From: "Stephen [kiwin] PALM" <[email-masked]>
Date: Thu, 30 Jun 2011 07:41:21 -0700

Agreed. I would phrase it this way:
How to do IPv6 in an IPv4 world.

Some points from the Description:
  > increasingly available in home gateway devices.

This is only *part* of the story.  *Users* have lots of IPv4
devices in their home.

  > o service discovery
This is already well handled by UPnP/DLNA

  > o managing routing

There were several snippets regarding routing/subnets/heterogeneous networking
technologies.  There is already work proceeding in IEEE P1905.1
to address issues related to multiple network technologies
via a MAC/PHY Abstraction Layer.  Also there are applications today
that expect a single subnet, so new architectures should not preclude
existing applications.

regards, kiwin

-- 
Stephen [kiwin] Palm   Ph.D.                          E:  [email-masked]
Senior Technical Director                             T: +1-949-926-PALM
Broadcom Broadband Communications Group               F: +1-949-926-7256
Irvine, California                               W: http://www.kiwin.com
Secondary email accounts:  [email-masked]  [email-masked]
[email-masked]  [email-masked]  [email-masked]  [email-masked]

---

From: "Stephen [kiwin] PALM" <[email-masked]>
Date: Thu, 30 Jun 2011 07:55:40 -0700

Thanks Mark for stating that.
It would really be helpful if this type of text is included in the description/charter.
The lack of of this information in the recently distributed material caused
several immediate allergic reactions...

regards, kiwin

---

From: "Weil, Jason" <[email-masked]>
Date: Thu, 30 Jun 2011 11:06:18 -0400

Mark,

100% in agreement with this stance.

Just to echo what Fernando has already stated, you can't completely ignore
IPv4 in the home network especially when you are talking about a
multi-segmented network. For example RFC6204 calls for a separate /64 on
each LAN interface per the L-2 requirement. In IPv4 these interfaces
nearly always operate in bridged mode. Supporting bridged IPv4 and routed
IPv6 on the same physical interface could pose a challenge.

Overall I like the concept of not breaking core IPv4 functionality while
focussing all new functionality to IPv6.

Jason

On 6/30/11 5:57 AM, "Mark Townsley" <[email-masked]> wrote:

>around this topic can be summed up as stating that homenet deliverables
>will:
>
>In other words, anything we do for the IPv6 homenet cannot actively break
>what's already running on IPv4. Also, trying to define what the IPv4 home
>network should be has long reached a point of diminishing returns given
>the effort in doing so coupled with our ability to significantly affect
>what's already deployed. There's still hope we can help direct IPv6, as
>such that is homenet's primary focus.  However, when we can define
>something that is needed for IPv6 in a way that is also useful for IPv4
>without making significant concessions, we should go ahead and do so.
>
>- Mark
>
>
>
>>> I think this deserves a problem statement that clearly describes what
>>>we expect to be able to do (but currently can't), etc. And, if this is
>> IPv4 should be excluded because it's a dead end, and we all know it.
>>We're just disagreeing when it's going to die and how.
>>
>> --
>fun mailing list
>[email-masked]
>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.

---

From: "Stephen [kiwin] PALM" <[email-masked]>
Date: Thu, 30 Jun 2011 08:09:50 -0700

> focussing all new functionality to IPv6.

It is more than just IPv4 functionality... it is all the deployed
applications and devices that utilize IPv4.... and for whatever
reason, cannot be "upgraded" to IPv6. 8-)

regards, kiwin

> On 6/30/11 5:57 AM, "Mark Townsley"<[email-masked]>  wrote:
>
>>

---

From: Mark Townsley <[email-masked]>
Date: Thu, 30 Jun 2011 17:13:59 +0200

> several immediate allergic reactions...

I'm happy to include it in the next rev.

- Mark

---

From: Keith Moore <[email-masked]>
Date: Thu, 30 Jun 2011 11:46:30 -0400

> - be IP-agnostic whenever possible

I'd like for this group to relax the "wherever possible" bit, so as to not preclude solutions where IPv6 can do a better job than IPv4.

IPv4 is a dinosaur gasping for its last breaths.

Keith

---

From: Fernando Gont <[email-masked]>
Date: Thu, 30 Jun 2011 12:59:20 -0300

> IPv4 is a dinosaur gasping for its last breaths.

Just curious: when you expect IPv4 to be gone? (including "gone" from
home and enterprise networks)

Thanks,

---

From: Keith Moore <[email-masked]>
Date: Thu, 30 Jun 2011 12:05:26 -0400

> home and enterprise networks)

I think it will be used for email and the web for at least ten years.
I think there will be a need to talk to legacy IPv4-only devices for about that long, perhaps a bit longer.
But IPv4 is already difficult to use for a great many applications, and it will only get worse with the imposition of LSN.  A home network that only supports IPv4, or which makes IPv6 as crippled as IPv4, is not a desirable goal.

Keith

---

From: Martin Rex <[email-masked]>
Date: Thu, 30 Jun 2011 18:14:18 +0200 (MEST)

Keith Moore wrote:
> 
> Perimeter security of some kind is probably appropriate.

Not just appropriate, it is an indispensible prerequisite.

>
> That doesn't mean that it has to look like firewalls do today.

Not necessarily.  But any sensible security requirements and
primarily the requirement of the smallest possible attack surface
amount to it.  If it has to walk like a duck and quack like a duck,
just use a duck instead of trying to retrain a goat.

>
> For one thing, users shouldn't have to muck with the details of
> which ports to allow.

_Unless_ they want to make a service accessible to the internet
with software produced by folks or companys which prioritize
features and merchantability far over security, quality and robustness
-- which is to say 99.999% of the available software.

>
> And the idea that every application server on a home network needs
> to negotiate access through some application-specific external server
> (as is generally the case with NATs today) is also ridiculous.

No, it is a simple technical problem that can be solved with a few
lines of extra code for those few applications where it acutally matters.

Just as democracy is the worst form of government except all the
others that have been tried (attributed to Winston Churchill).

Home networks should ALWAYS be NATed to the internet, so that it is
not possible to provide a simple policy switch to make everything on
the home network fully accessible from the internet, because any
such switch will inevitably be abused much more often by the bad,
poor novices and ignorant than sensibly employed by the needy and
security conscious.

Black-listing doesn't provide security, it always amounts to
obscurity and security theater.

Anything else than whitelisting is irresponsible security-wise.
And dynamic whitelisting (the motivation behind NAT-PMP) is even better.

Privacy is another issue.  The current custom here in Germany is that
the external IP-Address on your home gateway is dynamically assigned,
it changes on every new assignment, i.e. when the DSL connection
is reestablished after a carrier loss or cable disconnect,
whenever you ask your DSL router for it, and at least once
every 24 hours.

While this does not provide perfect privacy protection, it is a
good start.  For many internet usage scenarios, the use of a
longterm static IP-Address for home users would be completely
irresponsible with respect to data privacy, and would likely make
any logging of client IP-Addresses on servers unconditionally
illegal in European countries.

With respect to privacy, anything besides striclty voluntary,
well-informed opt-in and anytime easy opt-out again, is a non-starter.

No application, unless it absolutely, positively and unavoidably needs
to should use a fixed/static address without the affected folks
having provided conscious and clear consent.

-Martin

---

From: Keith Moore <[email-masked]>
Date: Thu, 30 Jun 2011 12:33:57 -0400

> Not just appropriate, it is an indispensible prerequisite.

I could take some issue with the indispensable part, because I also think that PCs are dinosaurs.  For a sufficiently small home network, there's a point where a firewall could provide very little marginal gain in exchange for the complexity and fragility that come with it.  

I do think that some sort of perimeter security should be part of a home network architecture, but I'd strongly object to the idea that hosts and appliances don't need to be secure because they can expect a firewall to provide their security for them.

> amount to it. 

The mostly commonly kinds of firewalls used today do anything but that.

> -- which is to say 99.999% of the available software.

a.  Maybe part of what HOMENET should do is establish security expectations for appliances and applications intended to provide services from such an environment.
b.  Get out of the habit of thinking that using IP addresses and port numbers as authentication tokens is in any way sane or secure.

> lines of extra code for those few applications where it acutally matters.

That's a completely incorrect and ridiculous statement.

> poor novices and ignorant than sensibly employed by the needy and

Another completely ridiculous statement.  You're trying to cripple home networks.  More generally, you're arguing for the perpetuation of hacks that never did work very well, instead of leaving room for better mechanisms to be developed.

> And dynamic whitelisting (the motivation behind NAT-PMP) is even better.

Whitelisting might be fine.  Basing that whitelist on port numbers and IP addresses is insane.  And users need better ways to manage the whitelist than typing in arcane information that they don't understand anyway for each service that they want to permit.

> illegal in European countries.

Dynamically assigned addresses don't provide any privacy protection if there's some service (like Dynamic DNS) that always points to the current address.  Again, you're trying to perpetuate brain damage.

> well-informed opt-in and anytime easy opt-out again, is a non-starter.

That much I agree with.  We disagree about the mechanisms.

> having provided conscious and clear consent.

Ridiculous.

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 30 Jun 2011 12:36:36 -0400

On Jun 30, 2011, at 12:33 PM, Mark Townsley wrote:
> Yes, and I think that IPv6 should naturally do a better job than IPv4 in the cases where it can. 
> 
> My original mail had this restatement of the above, which I think gets closer to what you want:
> 
>>> However, when we can define something that is needed for IPv6 in a way that is also useful for IPv4 without making significant concessions, we should go ahead and do so.

when the group can define something that is useful in IPv6, it shouldn't matter whether it's also useful for IPv4.

please don't constrain home networks to work only within the confines of IPv4 brain damage.

Keith

---

From: james woodyatt <[email-masked]>
Date: Thu, 30 Jun 2011 11:21:13 -0700

> please don't constrain home networks to work only within the confines of IPv4 brain damage.

I suspect what Mr. Townsley and Mr. Arkko are aiming at here is that if FUN can come up with a scheme to make routed home subnetworks work with delegated IPv6 prefixes, then it is probably not too far-fetched that the same scheme could be trivially extended for assigning IPv4 subnets from the RFC 1918 private realm to support dual-stack routed home subnetworks.

I'm not expecting home networks to be able to run IPv6-only with the IPv4 Internet mapped to 64:ff9b::/96 through NAT64 for several more years yet.  There's a whole crapload of legacy IPv4-only devices in the average home theater system today that nobody wants to cut off from the Internet just yet.

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 01 Jul 2011 06:31:53 +0900

> focussing all new functionality to IPv6.

Remember that IPv6 became unusably complex by impossible attempts
to add new functionality not available with IPv4, which implies
that there is no such thing as new functionality of IPv6.

E.g. DHCPv4 is better than not-really-stateless configuration
by ND.

> home and enterprise networks)

It will be long after IPv6 gone (excluding "gone" from home and
enterprise networks, because it is not really there).

						Masataka Ohta

---

From: Mark Andrews <[email-masked]>
Date: Fri, 01 Jul 2011 09:20:35 +1000

In message <[email-masked]>, james woodyatt wri
tes:
> I suspect what Mr. Townsley and Mr. Arkko are aiming at here is that if FUN c
> an come up with a scheme to make routed home subnetworks work with delegated 
> IPv6 prefixes, then it is probably not too far-fetched that the same scheme c
> ould be trivially extended for assigning IPv4 subnets from the RFC 1918 priva
> te realm to support dual-stack routed home subnetworks.
> 
> I'm not expecting home networks to be able to run IPv6-only with the IPv4 Int
> ernet mapped to 64:ff9b::/96 through NAT64 for several more years yet.  There
> 's a whole crapload of legacy IPv4-only devices in the average home theater s
> ystem today that nobody wants to cut off from the Internet just yet.

I'm expecting home nets to be dual stacked for 10+ years after IPv6
is common to the home (2-5) years.  If the home gateway has DS-Lite
support then that provides a better solution than NAT 444.  It also
continues to work when the home net goes IPv6 only with the home
gateway passing on the DS-Lite parameters from the ISP.

Consumer electronics lasts 10+ years.  I'm still using my DOCSIS
1.0 modem 8+ years.  My router hardware is 13+ years old, the
software is newer and is the 6in4 tunnel end point.  I've got TV's
of similar vintage.

---

From: Martin Rex <[email-masked]>
Date: Fri, 1 Jul 2011 01:46:12 +2600 (MEST)

> not be pre-ordained that this WG should assume NAT as a solution?

You absolutely want to have fairly fixed addresses within
your home network, and you absolutely want to have a short-lived
ephemeral IP-Address assigned on your internet side of your
home gateway for the purpose of privacy.

Otherwise the number of very unpleasant surprises, including
stuff like this:

   http://www.theregister.co.uk/2011/06/30/xbox_swat_police_rait/

is going to become quite popular.  And that is really among the
mild unpleasant things if every bit that floats in and out
your internet gatway has your name stamped on it visibly
to everyone.

-Martin

---

From: james woodyatt <[email-masked]>
Date: Thu, 30 Jun 2011 17:09:40 -0700

On Jun 30, 2011, at 18:46 , Martin Rex wrote:
> 
> And that [false police report incident] is really among the mild unpleasant things...

It's also not even remotely relevant.  Under the regime where that incident happened, it's not even news anymore when the police do that without any provocation at all.  There is nothing about NAT or dynamic subscriber IP assignment that provides any mitigation whatsoever of the risks entailed by living in a regime like that.

---

From: Keith Moore <[email-masked]>
Date: Thu, 30 Jun 2011 21:11:11 -0400

> home gateway for the purpose of privacy.

No, *you* want these things.  I do not, and imposing them is not in the interests of users in general.

>   http://www.theregister.co.uk/2011/06/30/xbox_swat_police_rait/

Nowhere in this article does it say that the user had a static IP address.  And as I indicated earlier, even with a dynamic IP address, there are frequently other ways to find a host's IP address.  If you force all hosts on a home network to have dynamic IP addresses, you break applications that need stable addresses.  If you don't force all hosts on a home network to have dynamic IP addresses, those that don't need stable addresses can still get ephemeral addresses via privacy addresses, DHCP, or other means.

You keep arguing for the perpetuation of bad hacks because of accidental properties of those hacks.  I'd rather have well-designed mechanisms that are tailor made to suit particular purposes.  

Keith

---

From: "JP Vasseur (jvasseur)" <[email-masked]>
Date: Fri, 1 Jul 2011 00:30:14 -0500

I'd like to second the relaxation of "wherever possible", which may lead to a suboptimal solution for several components.

JP Vasseur
Cisco Fellow

Sent from Blackberry

----- Original Message -----
From: Mark Townsley [mailto:[email-masked]]
Sent: Thursday, June 30, 2011 11:33 AM
To: Keith Moore <[email-masked]>
Cc: IETF Discussion <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [fun] [homegate] HOMENET working group proposal

- Mark