Subject: Re: [fun] [homegate] HOMENET working group proposal
From: Mikael Abrahamsson <[email-masked]>
To: Martin Focazio <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 1 Jul 2011 07:23:47 +0200 (CEST)
List-Id: "FUture home Networking \(FUN\)" <fun.ietf.org>

On Thu, 30 Jun 2011, Martin Focazio wrote:

> You assume at Alice CAN select a service provider. In a large part of
> the USA your choices are nil. You have a single wireline provider or
> you don't have a connection.

I don't see why the IETF should spend time on IPv4 because of some 
political problem in certain countries which makes the market not work 
properly.

IPv4 is legacy, IPv6 is where the development effort should be, when IPv6 
offers more functionality then things will most likely sort themselves 
out.

Personally I believe video conferencing is the killer app. I have problems 
getting video calls to work when both are behind NAT, it works just fine 
with one person being behind NAT (and the other one not having firewall 
configured so it's stopping the traffic). With IPv6 we just need to sort 
out the firewall problem. My mom is very impressed by being able to 
videocall her grandchild and follow his development, and if I told her 
it'd cost 200 USD extra to make it work (better), either she or I would 
spend the money.

-- 
Mikael Abrahamsson    email: [email-masked]

From: james woodyatt <[email-masked]>
Date: Thu, 30 Jun 2011 16:51:29 -0700
To: [email-masked], [email-masked]
Subject: Re: [fun] [homegate] HOMENET working group proposal

On Jun 30, 2011, at 16:10 , Robert Raszuk wrote:
> 
> ...when there is new killer app which works only over v6...

There's another conditional that may be more relevant.

When there is a new "killer" application that doesn't work when one endpoint is IPv4-only and the other is attached to a 3GPP network with IPv6-only service and using NAT64 with the well-known 64:ff9b::/64 prefix, and optionally a bump-in-the-host to provide an IPv4 networking API to applications.  I happen to be aware of a whole family of interesting applications that are broken by such configurations, and I'm pretty sure they will remain broken into the foreseeable future.  Those configurations are already here in some parts of the Internet, and when these applications I'm thinking about are deployed on those networks (they are not currently, but... mene mene tekel upharsin), they will fail.

And whose fault will that be?  Not mine, brother.  Not mine.

Is your service provider breaking those awesome applications by not offering full dual-stack service?  If so, then you need to get a new service provider.  Either get one that offers full dual-stack over 3GPP so your applications can connect with IPv4-only endpoints, or get one that offers full dual-stack over first-mile wireline to your site, so your applications can connect to IPv4-impaired mobile endpoints.

The key thing here is that by Alice choosing to use one service provider over another, she can make Bob's application fail, and vice versa.  The mobile service providers that don't have enough IPv4 addresses to serve all their customers are in a bind and can't budge.  The wireline service providers who have 5-10 years of IPv4 addresses in reserve are the ones whistling past the graveyard.

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

To: james woodyatt <[email-masked]>
From: Mark Andrews <[email-masked]>
Date: Fri, 01 Jul 2011 09:20:35 +1000
Cc: [email-masked], IETF Discussion <[email-masked]>
Subject: Re: [fun] [homegate] HOMENET working group proposal

In message <[email-masked]>, james woodyatt wri
tes:
> On Jun 30, 2011, at 09:36 , Keith Moore wrote:
> > 
> > when the group can define something that is useful in IPv6, it shouldn't ma
> tter whether it's also useful for IPv4.
> > please don't constrain home networks to work only within the confines of IP
> v4 brain damage.
> 
> 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.

> --
> james woodyatt <[email-masked]>
> member of technical staff, core os networking
> 
> 
> 
> _______________________________________________
> fun mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/fun
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

Date: Fri, 01 Jul 2011 01:10:57 +0200
From: Robert Raszuk <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [fun] [homegate] HOMENET working group proposal
Reply-To: [email-masked]

I think this is a great WG proposal and I fully support it's creation.

However my ISP is telling me that it has sufficient pool of IPv4 
addresses for the min next 5-10 years so rolling v6 for residential 
users is completely not that much appealing to him.

IETF can build many specs recommending v6 deployments, protocol 
extensions and network architectures. Unfortunately before the day  when 
there is first attractive real content available online _only_ via v6 or 
when there is new killer app which works only over v6 I think the world 
will become more and more fragmented into islands of v4, v4v6 and v6 only.

The issue is not technical here and IETF will not I am afraid be able to 
fix it.

The issue is purely business driven and till all providers get clear 
message from their users that they must have v6 as they can not google 
anymore, pay their bills, use new fancy holographic movie downloader app 
(just as examples) the migration towards v6 may take not 10 but 50 to 
100 years.

Cheers,
R.

From: "Edward Arthurs" <[email-masked]>
To: <[email-masked]>
Date: Thu, 30 Jun 2011 11:40:47 -0700
Organization: Legacy International Inc.
Subject: Re: [fun] [homegate] HOMENET working group proposal
Reply-To: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_2689_01CC371A.8DC929B0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

The only thing aside from the network end that I see is people who have
figured out the IPv4 scheme.

Now have to figure out the IPv6 scheme, and the size has of the I.P. address
has them scratching their heads, not everyone has heard of IPv6 yet.

Thank You

Edward Arthurs

Manager of Network Installations

Legacy Inmate Communications

Legacy Contact Center

Legacy Long Distance Intl. Inc

10833 Valley View Street

Suite 150

Cypress, California 90630-5040

Office 1-800-577-5534 ext. 207

Direct 1-800-956-1595

Fax    1-714-827-7545

E-Mail: [email-masked]

E-Mail: [email-masked]

 

This e-mail (including any attachments) may contain information that is
private, confidential, or protected by attorney-client or other privilege.

If you received this e-mail in error, please delete it from your system
without copying it and notify sender by reply e-mail, so that our records
can be corrected.

No trees were harmed as a result of this e-mail; however, many electrons
were severely inconvenienced.

 

------=_NextPart_000_2689_01CC371A.8DC929B0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PostalCode"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"State"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"Street"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"address"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PlaceType"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PlaceName"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>The only thing aside from the network end that I see =
is
people who have figured out the IPv4 =
scheme.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Now have to figure out the IPv6 scheme, and the size =
has of
the I.P. address has them scratching their heads, not everyone has heard =
of
IPv6 yet.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Thank You</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Edward Arthurs<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Manager of Network =
Installations</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Legacy Inmate =
Communications</span></font><o:p></o:p></p>

<p class=3DMsoNormal><st1:place w:st=3D"on"><st1:PlaceName =
w:st=3D"on"><font size=3D2
  face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Legacy</span></font></st1:Pl=
aceName><font
 size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'> <st1:PlaceName
 w:st=3D"on">Contact</st1:PlaceName> <st1:PlaceType =
w:st=3D"on">Center</st1:PlaceType></span></font></st1:place><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><o:p></o:p></span></font></p=
>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Legacy Long Distance Intl. =
Inc<o:p></o:p></span></font></p>

<p class=3DMsoNormal><st1:Street w:st=3D"on"><st1:address =
w:st=3D"on"><font size=3D2
  face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial'>10833 =
Valley View
  Street</span></font></st1:address></st1:Street><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'><o:p></o:p></span></font></p=
>

<p class=3DMsoNormal><st1:address w:st=3D"on"><st1:Street =
w:st=3D"on"><font size=3D2
  face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Suite</span></font></st1:Str=
eet><font
 size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'> =
150</span></font></st1:address><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><o:p></o:p></span></font></p=
>

<p class=3DMsoNormal><st1:place w:st=3D"on"><st1:City w:st=3D"on"><font =
size=3D2
  face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Cypress</span></font></st1:C=
ity><font
 size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>, <st1:State
 w:st=3D"on">California</st1:State> <st1:PostalCode =
w:st=3D"on">90630-5040</st1:PostalCode></span></font></st1:place><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><o:p></o:p></span></font></p=
>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Office 1-800-577-5534 ext. =
207<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Direct 1-800-956-1595<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Fax&nbsp;&nbsp;&nbsp; =
1-714-827-7545</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>E-Mail: <a =
href=3D"mailto:[email-masked]">[email-masked]</a></span></f=
ont><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>E-Mail: <a =
href=3D"mailto:[email-masked]">[email-masked]</=
a><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font><font size=3D2 face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;font-family:
Arial;color:blue'>This e-mail (including any attachments) may contain
information that is private, confidential, or protected by =
attorney-client or
other privilege.<o:p></o:p></span></font></p>

<p><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;font-family:
Arial;color:blue'>If you received this e-mail in error, please delete it =
from
your system without copying it and notify sender by reply e-mail, so =
that our
records can be corrected.<o:p></o:p></span></font></p>

<p><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;font-family:
Arial;color:blue'>No trees were harmed as a result of this e-mail; =
however,
many electrons were severely =
inconvenienced.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font><font size=3D2 face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------=_NextPart_000_2689_01CC371A.8DC929B0--

From: james woodyatt <[email-masked]>
Date: Thu, 30 Jun 2011 11:21:13 -0700
To: [email-masked]
Cc: IETF Discussion <[email-masked]>
Subject: Re: [fun] [homegate] HOMENET working group proposal

On Jun 30, 2011, at 09:36 , Keith Moore wrote:
> 
> 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.

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

Date: Thu, 30 Jun 2011 19:19:05 +0200
From: Jari Arkko <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: [fun] status of the homenet effort

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

From: Keith Moore <[email-masked]>
Date: Thu, 30 Jun 2011 12:36:36 -0400
To: Mark Townsley <[email-masked]>
Cc: IETF Discussion <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [fun] [homegate] HOMENET working group proposal

On Jun 30, 2011, at 12:33 PM, Mark Townsley wrote:
>>>=20
>>> 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:
>>>=20
>>> - 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
>>=20
>> 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.
>=20
> Yes, and I think that IPv6 should naturally do a better job than IPv4 =
in the cases where it can.=20
>=20
> My original mail had this restatement of the above, which I think gets =
closer to what you want:
>=20
>>> 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: Mark Townsley <[email-masked]>
Date: Thu, 30 Jun 2011 18:36:02 +0200
To: "Weil, Jason" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [fun] status of the homenet effort

Thank you for the feedback, keep it coming.

On Jun 30, 2011, at 4:14 PM, Weil, Jason wrote:

> Mark, Raplh, Jari, et all,
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> FWIW, I would also add that the five topics in the charter are also =
listed
> in order
> Of priority at least for me.
>=20
>=20
> Thanks,
>=20
> Jason
>=20
>=20
> On 6/29/11 5:46 AM, "Mark Townsley" <[email-masked]> wrote:
>=20
>>=20
>> All,
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> Thanks, and see you on the list and in Quebec.
>>=20
>> - Mark
>>=20
>>=20
>> On Jun 29, 2011, at 10:35 AM, Jari Arkko wrote:
>>=20
>>> I wanted to provide an update of the situation with this working =
group
>>> proposal.
>>>=20
>>> 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").
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> 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).
>>>=20
>>> This is the most recent version of the charter we should discuss:
>>>=20
>>> Home Networks (homenet)
>>> -----------------------------------
>>>=20
>>> Current Status: Proposed
>>> Last Edit: Wednesday, June 29th, 2011
>>>=20
>>> Chairs:
>>> TBD
>>>=20
>>> Internet Area Directors:
>>> Ralph Droms <[email-masked]>
>>> Jari Arkko <[email-masked]>
>>>=20
>>> Internet Area Advisor:
>>> Jari Arkko <[email-masked]>
>>>=20
>>> Routing Area Technical Advisor:
>>> TBD
>>>=20
>>> Security Area Technical Advisor:
>>> TBD
>>>=20
>>> Mailing Lists:
>>> General Discussion: [email-masked]
>>> To Subscribe: https://www.ietf.org/mailman/listinfo/fun
>>> Archive: http://www.ietf.org/mail-archive/web/fun
>>>=20
>>> Description of Working Group:
>>>=20
>>> This working group focuses on the evolving networking technology
>>> within and among relatively small =B3residential home=B2 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:
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> 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:
>>>=20
>>> o prefix configuration for routers
>>> o managing routing
>>> o name resolution
>>> o service discovery
>>> o network security
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> Milestones:
>>>=20
>>> 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
>>>=20
>>> _______________________________________________
>>> fun mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/fun
>>=20
>> _______________________________________________
>> fun mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/fun
>=20
>=20
> 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: Mark Townsley <[email-masked]>
Date: Thu, 30 Jun 2011 18:33:58 +0200
To: Keith Moore <[email-masked]>
Cc: IETF Discussion <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [fun] [homegate] HOMENET working group proposal

On Jun 30, 2011, at 5:46 PM, Keith Moore wrote:

>=20
> On Jun 30, 2011, at 5:57 AM, Mark Townsley wrote:
>=20
>>=20
>> 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:
>>=20
>> - 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
>=20
> 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.

Yes, and I think that IPv6 should naturally do a better job than IPv4 in =
the cases where it can.=20

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.

- Mark

>=20
> IPv4 is a dinosaur gasping for its last breaths.
>=20
> Keith
>=20
>=20
> _______________________________________________
> homegate mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homegate

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Thu, 30 Jun 2011 12:21:37 -0400
To: "Stephen [kiwin] PALM" <[email-masked]>
Cc: Keith Moore <[email-masked]>, IETF Discussion <[email-masked]>, [email-masked]
Subject: Re: [fun] [homegate] HOMENET working group proposal

On Jun 30, 2011, at 12:17 PM, "Stephen [kiwin] PALM" <[email-masked]> wro=
te:

> It is not for "us" to decide when a user's network is not worth expending
> any more energy on. They have deployed their network...
> and do not want to expend any more energy themselves.  If their SP deploys=

> IPv6 inelegantly, the user would have a lot of frustration/work.  Which
> will generate many expensive tech support calls... and potentially lost cu=
stomers.

Agreed that we need to avoid any disruptions of existing networks, devices a=
nd deployment scenarios.  I think we should avoid expending energy on *new* f=
unctions for IPv4.

- Ralph

>=20
> It's not the protocols... it's the DEPLOYED APPLICATIONS and DEVICES that u=
sers have.
>=20
> regards, kiwin
>=20
> On 6/30/2011 9:11 AM, Ralph Droms (rdroms) wrote:
>>=20
>> "Gone" isn't so important as "not worth expending any more energy on.". S=
o I'm with Keith and would like to find some words like "when it doesn't tak=
e any more work."
>>=20
>> - Ralph
>>=20
>> On Jun 30, 2011, at 12:00 PM, "Fernando Gont"<[email-masked]>  wrot=
e:
>>=20
>>> On 06/30/2011 12:46 PM, Keith Moore wrote:
>>>> I'd like for this group to relax the "wherever possible" bit, so as to n=
ot preclude solutions where IPv6 can do a better job than IPv4.
>>>>=20
>>>> IPv4 is a dinosaur gasping for its last breaths.
>>>=20
>>> Just curious: when you expect IPv4 to be gone? (including "gone" from
>>> home and enterprise networks)
>>>=20
>>> Thanks,
>>> --
>>> Fernando Gont
>>> e-mail: [email-masked] || [email-masked]
>>> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>>>=20
>>>=20
>>>=20
>>> _______________________________________________
>>> fun mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/fun
>> _______________________________________________
>> fun mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/fun
>>=20
>=20
> --=20
> 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]
>=20

Date: Thu, 30 Jun 2011 09:17:22 -0700
From: "Stephen [kiwin] PALM" <[email-masked]>
To: "Ralph Droms (rdroms)" <[email-masked]>
Cc: Keith Moore <[email-masked]>, IETF Discussion <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [fun] [homegate] HOMENET working group proposal

It is not for "us" to decide when a user's network is not worth expending
any more energy on. They have deployed their network...
and do not want to expend any more energy themselves.  If their SP deploys
IPv6 inelegantly, the user would have a lot of frustration/work.  Which
will generate many expensive tech support calls... and potentially lost customers.

It's not the protocols... it's the DEPLOYED APPLICATIONS and DEVICES that users have.

regards, kiwin

On 6/30/2011 9:11 AM, Ralph Droms (rdroms) wrote:
>
> "Gone" isn't so important as "not worth expending any more energy on.". So I'm with Keith and would like to find some words like "when it doesn't take any more work."
>
> - Ralph
>
> On Jun 30, 2011, at 12:00 PM, "Fernando Gont"<[email-masked]>  wrote:
>
>> On 06/30/2011 12:46 PM, Keith Moore wrote:
>>> 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.
>>
>> Just curious: when you expect IPv4 to be gone? (including "gone" from
>> home and enterprise networks)
>>
>> Thanks,
>> --
>> Fernando Gont
>> e-mail: [email-masked] || [email-masked]
>> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>>
>>
>>
>> _______________________________________________
>> fun mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/fun
> _______________________________________________
> fun mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/fun
>

-- 
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: "Ralph Droms (rdroms)" <[email-masked]>
Date: Thu, 30 Jun 2011 12:11:31 -0400
To: "Fernando Gont" <[email-masked]>
Cc: [email-masked], Keith Moore <[email-masked]>, IETF Discussion <[email-masked]>
Subject: Re: [fun] [homegate] HOMENET working group proposal

"Gone" isn't so important as "not worth expending any more energy on.". So I=
'm with Keith and would like to find some words like "when it doesn't take a=
ny more work."

- Ralph

On Jun 30, 2011, at 12:00 PM, "Fernando Gont" <[email-masked]> wrote:

> On 06/30/2011 12:46 PM, Keith Moore wrote:
>> I'd like for this group to relax the "wherever possible" bit, so as to no=
t preclude solutions where IPv6 can do a better job than IPv4.
>>=20
>> IPv4 is a dinosaur gasping for its last breaths.
>=20
> Just curious: when you expect IPv4 to be gone? (including "gone" from
> home and enterprise networks)
>=20
> Thanks,
> --=20
> Fernando Gont
> e-mail: [email-masked] || [email-masked]
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>=20
>=20
>=20
> _______________________________________________
> fun mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/fun

From: Keith Moore <[email-masked]>
Date: Thu, 30 Jun 2011 12:05:26 -0400
To: Fernando Gont <[email-masked]>
Cc: IETF Discussion <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [fun] [homegate] HOMENET working group proposal

On Jun 30, 2011, at 11:59 AM, Fernando Gont wrote:

> On 06/30/2011 12:46 PM, Keith Moore wrote:
>> 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.
>>=20
>> IPv4 is a dinosaur gasping for its last breaths.
>=20
> Just curious: when you expect IPv4 to be gone? (including "gone" from
> 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

Sender: Fernando Gont <[email-masked]>
Date: Thu, 30 Jun 2011 12:59:20 -0300
From: Fernando Gont <[email-masked]>
To: Keith Moore <[email-masked]>
Cc: IETF Discussion <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [fun] [homegate] HOMENET working group proposal

On 06/30/2011 12:46 PM, Keith Moore wrote:
> 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.

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

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

From: Keith Moore <[email-masked]>
Date: Thu, 30 Jun 2011 11:46:30 -0400
To: Mark Townsley <[email-masked]>
Cc: [email-masked], [email-masked], IETF Discussion <[email-masked]>
Subject: Re: [fun] [homegate] HOMENET working group proposal

On Jun 30, 2011, at 5:57 AM, Mark Townsley wrote:

>=20
> 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:
>=20
> - 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

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: Mark Townsley <[email-masked]>
Date: Thu, 30 Jun 2011 17:13:59 +0200
To: "Stephen [kiwin] PALM" <[email-masked]>
Cc: IETF Discussion <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [fun] [homegate] HOMENET working group proposal

On Jun 30, 2011, at 4:55 PM, Stephen [kiwin] PALM wrote:

> 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...

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

- Mark

>=20
> regards, kiwin
>=20
> On 6/30/2011 2:57 AM, Mark Townsley wrote:
>>=20
>> 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:
>>=20
>> - 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
>>=20
>> 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.
>>=20
>> - Mark
>>=20
>>=20
>>=20
>> On Jun 30, 2011, at 9:25 AM, Mikael Abrahamsson wrote:
>>=20
>>> On Thu, 30 Jun 2011, Fernando Gont wrote:
>>>=20
>>>> 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)
>>>=20
>>> 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.
>>>=20
>>>> 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.
>>>=20
>>> 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.
>>>=20
>>> --
>>> Mikael Abrahamsson    email: [email-masked]
>>> _______________________________________________
>>> homegate mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/homegate
>>=20
>> _______________________________________________
>> homegate mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/homegate
>>=20
>=20
> --=20
> 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]
>=20
> _______________________________________________
> homegate mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homegate

Date: Thu, 30 Jun 2011 08:09:50 -0700
From: "Stephen [kiwin] PALM" <[email-masked]>
To: "Weil, Jason" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, IETF Discussion <[email-masked]>
Subject: Re: [fun] [homegate] HOMENET working group proposal

On 6/30/2011 8:06 AM, Weil, Jason wrote:

> Overall I like the concept of not breaking core IPv4 functionality while
> 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:
>
>>
>> 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:
>>>
>>>> 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.
>>>
>>> --
>>> Mikael Abrahamsson    email: [email-masked]
>>> _______________________________________________
>>> homegate mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/homegate
>>
>> _______________________________________________
>> 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.
> _______________________________________________
> fun mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/fun
>

-- 
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: "Weil, Jason" <[email-masked]>
To: Mark Townsley <[email-masked]>, "[email-masked]" <[email-masked]>, IETF Discussion <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 30 Jun 2011 11:06:18 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [fun] [homegate] HOMENET working group proposal

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:

>
>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:
>>
>>> 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.
>>
>> --
>> Mikael Abrahamsson    email: [email-masked]
>> _______________________________________________
>> homegate mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/homegate
>
>_______________________________________________
>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 propri=
etary information, which is privileged, confidential, or subject to copyrig=
ht belonging to Time Warner Cable. This E-mail is intended solely for the u=
se 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 dissem=
ination, distribution, copying, or action taken in relation to the contents=
 of and attachments to this E-mail is strictly prohibited and may be unlawf=
ul. If you have received this E-mail in error, please notify the sender imm=
ediately and permanently delete the original and any copy of this E-mail an=
d any printout.

Date: Thu, 30 Jun 2011 23:55:55 +0900
From: Erik Kline <[email-masked]>
To: "Weil, Jason" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [fun] status of the homenet effort

> 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.

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

Date: Thu, 30 Jun 2011 07:55:40 -0700
From: "Stephen [kiwin] PALM" <[email-masked]>
To: "Mark Townsley" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, IETF Discussion <[email-masked]>
Subject: Re: [fun] [homegate] HOMENET working group proposal

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

On 6/30/2011 2: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:
>>
>>> 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.
>>
>> --
>> 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
>

-- 
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]

Date: Thu, 30 Jun 2011 07:41:21 -0700
From: "Stephen [kiwin] PALM" <[email-masked]>
To: "Fernando Gont" <[email-masked]>
Cc: IETF Discussion <[email-masked]>, [email-masked], "[email-masked]" <[email-masked]>
Subject: Re: [fun] [homegate] HOMENET working group proposal

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

Some points from the Description:
  > o Service providers are deploying IPv6, and support for IPv6 is
  > 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

On 6/29/2011 11:51 PM, Fernando Gont wrote:
> 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,

-- 
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: "Weil, Jason" <[email-masked]>
To: Mark Townsley <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 30 Jun 2011 10:14:40 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [fun] status of the homenet effort

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.
>
>Thanks, and see you on the list and in Quebec.
>
>- Mark
>
>
>On Jun 29, 2011, at 10:35 AM, Jari Arkko wrote:
>
>> I wanted to provide an update of the situation with this working group
>>proposal.
>>
>> HOMENET is a new working group proposal, a variation of the
>>HOMEGATE/HOMENET theme that we discussed last year, but this time
>>looking at it from a different angle. The old effort was mostly focused
>>about what home gateways should do: forwarding, transport, and DNS
>>proxying issues. The new effort is about home networks themselves, in
>>particular what kind of network architecture and configuration is
>>necessary to support IPv6-based home networks. We view IPv4-based home
>>networks as "done" at this time (or perhaps as "cannot be changed
>>anyway").
>>
>> I have been discussing this effort in the background for the last
>>couple of month with Mark Townsley and others, and more publicly since
>>early June. The proposal has been brought to the IESG, IAB and some
>>directorates for discussion, and we've been going back and forth whether
>>this is ready to become a working group or needs to be run as a BOF in
>>Quebec City. The current plan is that the working group proposal goes to
>>IETF-wide review this week, and if the feedback from the community, IAB,
>>and the IESG is positive, we will create the working group just in time
>>for the IETF. Otherwise, the slot reserved in the agenda for the meeting
>>will be used to run the proposal as a BOF.
>>
>> In any case, I would like to solicit discussion on this topic, and
>>perhaps some early drafts as well. Please comment on the charter at
>>least.
>>
>> Note that the new proposal was called FUN at the time that we created
>>the list. It has now been renamed back to HOMENET to be more
>>descriptive. The list will be renamed soon as well (current subscribers
>>will stay).
>>
>> This is the most recent version of the charter we should discuss:
>>
>> Home Networks (homenet)
>> -----------------------------------
>>
>> Current Status: Proposed
>> Last Edit: Wednesday, June 29th, 2011
>>
>> Chairs:
>> TBD
>>
>> Internet Area Directors:
>> Ralph Droms <[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 =B3residential home=B2 networks. For
>> example, an obvious trend in home networking is the proliferation of
>> networking technology in an increasingly broad range and number of
>> devices. This evolution in scale and diversity sets some requirements
>> on IETF protocols. Some of the relevant trends include:
>>
>> o Multiple segments: While less complex L3-toplogies involving as few
>> subnets as possible are preferred in home networks for a variety of
>> reasons including simpler management and service discovery, the
>> introduction of more than one subnet into a home network is enough
>> to add complexity that needs to be addressed, and multiple
>> dedicated segments are necessary for some cases. For instance, a
>> common feature in modern home routers in the ability to support
>> both guest and private network segments. Also, link layer
>> networking technology is poised to become more heterogeneous, as
>> networks begin to employ both traditional Ethernet technology and
>> link layers designed for low-powered sensor networks. Finally,
>> similar needs for segmentation may occur in other cases, such as
>> separating building control or corporate extensions from the
>> Internet access network. Different segments may be associated with
>> subnets that have different routing and security policies.
>>
>> o Service providers are deploying IPv6, and support for IPv6 is
>> increasingly available in home gateway devices. While IPv6 resembles
>> IPv4 in many ways, it changes address allocation principles and allows
>> direct IP addressability and routing to devices in the home from the
>> Internet. This is a promising area in IPv6 that has proved challenging
>> in IPv4 with the proliferation of NAT.
>>
>> o End-to-end communication is both an opportunity and a concern as it
>> enables new applications but also exposes nodes in the internal
>> networks to receipt of unwanted traffic from the Internet. Firewalls
>> that restrict incoming connections may be used to prevent exposure,
>> however, this reduces the efficacy of end-to-end connectivity that
>> IPv6 has the potential to restore.
>>
>> Home networks need to provide the tools to handle these situations in
>> a manner accessible to all users of home networks. Manual
>> configuration is rarely, if at all, possible. The purpose of this
>> working group is to focus on this evolution, in particular as it
>> addresses the introduction of IPv6, by developing an architecture
>> addressing this full scope of requirements:
>>
>> o prefix configuration for routers
>> o managing routing
>> o name resolution
>> o service discovery
>> o network security
>>
>> The task of the group is to produce an architecture document that
>> outlines how to construct home networks involving multiple routers and
>> subnets. This document is expected to apply the IPv6 addressing
>> architecture, prefix delegation, global and ULA addresses, source
>> address selection rules and other existing components of the IPv6
>> architecture. The architecture document should drive what protocols
>> changes, if any, are necessary. Specific protocol work described below
>> is expected to be within the scope of the working group one the
>> architecture work is complete. However, the group is required to
>> review its charter and milestones with the IESG and IETF community
>> before submitting documents that make protocol changes. It is expected
>> that the group has to discuss some of the below solutions, however, in
>> order to complete the architecture work.
>>
>> The group will apply existing protocols to handle the five
>> requirements above. For prefix configuration, existing protocols are
>> likely sufficient, and at worst may need some small enhancements, such
>> as new options. For automatic routing, it is expected that existing
>> routing protocols can be used as is, however, a new mechanism may be
>> needed in order to turn a selected protocol on by default. For name
>> resolution and service discovery, extensions to existing
>> multicast-based name resolution protocols are needed to enable them to
>> work across subnets.
>>
>> For network security, the group shall document the concept of
>> "advanced security" as a further development of "simple security" from
>> RFC 6092. The main goal of this work is to enable a security policy
>> that adapts to IPv6 threats as they emerge, taking into account not
>> only traffic from the Internet at large, but within and leaving the
>> home network itself.
>>
>> It is expected that the working group will define a set of protocol
>> specifications to accomplish the five requirements from
>> above. However, it is not in the scope of the working group to define
>> entirely new routing protocols or address allocation protocols. As
>> noted, additional options or other small extensions may be necessary
>> to use the existing protocols in these new configuration tasks. The
>> working group shall also not make any changes to IPv6 protocols or
>> addressing architecture. Prefix configuration, routing, and security
>> related work shall not cause any changes that are not backwards
>> compatible to existing IPv6 hosts. There may be host visible changes
>> in the work on naming and discovery protocols, however. In its design,
>> the working group shall also consider security aspects and the impact
>> on manageability. The main focus of the working group is home
>> networks, but the group's results may also find applications in other
>> small networks.
>>
>> The working group will liaise with the relevant IETF working
>> groups. In particular, the group should work closely with the V6OPS
>> working group, review any use or extension of DHCP with the DHC
>> working group, and work with additional DNS requirements with the
>> DNSEXT and DNSOP working groups. If it turns out that additional
>> options are needed for a routing protocol, they will be developed in
>> the appropriate Routing Area working group, with the HOMENET working
>> group providing the architecture and requirements for such
>> enhancements. The working group will also liase with external
>> standards bodies where it is expected that there are normative
>> dependencies between the specifications of the two bodies.
>> It is expected that in the architecture definition stage liaising
>> with the Broadband Forum, DLNA, and UPnP Forum is necessary.
>>
>> Milestones:
>>
>> Jul 2011 Formation of the working group
>> Sep 2011 First WG draft on the architecture
>> Dec 2011 Submission of the architecture draft to the IESG as
>>Informational RFC
>> Dec 2011 Charter re-evaluation based on the architecture work
>> Dec 2011 First WG draft on prefix configuration
>> Dec 2011 First WG draft on routing
>> Jan 2012 First WG draft on name resolution
>> Feb 2012 First WG draft on service discovery
>> Feb 2012 First WG draft on perimeter security
>> Feb 2012 Start of routing related work in the relevant routing area
>>working group, if needed
>> Mar 2012 Submission of the prefix configuration draft to the IESG as
>>Standards Track RFC
>> Apr 2012 Submission of the routing draft to the IESG as Informational
>>RFC
>> Sep 2012 Submission of the name resolution draft to the IESG as
>>Standards Track RFC
>> Nov 2012 Submission of the service discovery draft to the IESG as
>>Standards Track RFC
>> Dec 2012 Submission of the perimeter security draft to the IESG as
>>Informational RFC
>>
>> _______________________________________________
>> fun mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/fun
>
>_______________________________________________
>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 propri=
etary information, which is privileged, confidential, or subject to copyrig=
ht belonging to Time Warner Cable. This E-mail is intended solely for the u=
se 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 dissem=
ination, distribution, copying, or action taken in relation to the contents=
 of and attachments to this E-mail is strictly prohibited and may be unlawf=
ul. If you have received this E-mail in error, please notify the sender imm=
ediately and permanently delete the original and any copy of this E-mail an=
d any printout.

Sender: Fernando Gont <[email-masked]>
Date: Thu, 30 Jun 2011 09:50:02 -0300
From: Fernando Gont <[email-masked]>
To: Keith Moore <[email-masked]>
Cc: IETF Discussion <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [fun] [homegate] HOMENET working group proposal

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

>> If our work focuses only on IPv6, I get the impression that we're 
>> 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.

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...
> 
> no, that's not fine.   that's painting ourselves (and the Internet)
> into a corner.

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,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

From: Keith Moore <[email-masked]>
Date: Thu, 30 Jun 2011 08:21:43 -0400
To: Fernando Gont <[email-masked]>
Cc: IETF Discussion <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [fun] [homegate] HOMENET working group proposal

On Jun 30, 2011, at 5:47 AM, Fernando Gont wrote:

> Jari,
>=20
> On 06/30/2011 06:38 AM, Jari Arkko wrote:
>> 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.=20
>=20
> 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?

hopefully!

> e.g., your home network would have multiple subnets (thanks to
> 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.

> If our work focuses only on IPv6, I get the impression that we're
> 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.

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

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

Keith

Content-class: urn:content-classes:message
Date: Thu, 30 Jun 2011 12:53:25 +0200
From: "Pascal Thubert (pthubert)" <[email-masked]>
To: "Jari Arkko" <[email-masked]>, "Fernando Gont" <[email-masked]>
Cc: IETF Discussion <[email-masked]>, [email-masked]
Subject: Re: [fun] [homegate] HOMENET working group proposal

> That is the plan. And when I say "differently", I mean differences
such as
>=20
> * prefix delegation
> * global addresses and firewalls instead of private addresses and NATs
> * across-subnet communication internally in the home can be routed,
not
> NATted
>=20

[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.=20

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

Sender: Fernando Gont <[email-masked]>
Date: Thu, 30 Jun 2011 07:40:17 -0300
From: Fernando Gont <[email-masked]>
To: Mark Townsley <[email-masked]>
Cc: [email-masked], [email-masked], IETF Discussion <[email-masked]>
Subject: Re: [fun] [homegate] HOMENET working group proposal

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:
>> 
>>> 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.
>> 
>> -- 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
> 

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

Date: Thu, 30 Jun 2011 12:02:53 +0200
From: Jari Arkko <[email-masked]>
To: Fernando Gont <[email-masked]>
Cc: IETF Discussion <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [fun] [homegate] HOMENET working group proposal

Fernando,

> 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? 

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
> PD), but a single IPv4 subnet?
>   

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.

> 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.
>   

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: Mark Townsley <[email-masked]>
Date: Thu, 30 Jun 2011 11:57:06 +0200
To: [email-masked], IETF Discussion <[email-masked]>, [email-masked]
Subject: Re: [fun] [homegate] HOMENET working group proposal

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.=20

- Mark

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

> On Thu, 30 Jun 2011, Fernando Gont wrote:
>=20
>> 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)
>=20
> 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.
>=20
>> 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.
>=20
> 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.
>=20
> --=20
> Mikael Abrahamsson    email: [email-masked]
> _______________________________________________
> homegate mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homegate

Sender: Fernando Gont <[email-masked]>
Date: Thu, 30 Jun 2011 06:47:29 -0300
From: Fernando Gont <[email-masked]>
To: Jari Arkko <[email-masked]>
Cc: IETF Discussion <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [fun] [homegate] HOMENET working group proposal

Jari,

On 06/30/2011 06:38 AM, Jari Arkko wrote:
> 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. 

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,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Date: Thu, 30 Jun 2011 11:38:31 +0200
From: Jari Arkko <[email-masked]>
To: Fernando Gont <[email-masked]>
Cc: IETF Discussion <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [fun] [homegate] HOMENET working group proposal

Fernando,

> 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)
>   

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

Date: Thu, 30 Jun 2011 11:31:57 +0200
From: Jari Arkko <[email-masked]>
To: Fernando Gont <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, IETF Discussion <[email-masked]>
Subject: Re: [fun] HOMENET working group proposal

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:
> 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, Ie
> 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:
> [....]
>   
>> 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.
>>     
>
> 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.
>
>
>   
>> 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.
>>     
>
> 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!
>   

From: Mark Townsley <[email-masked]>
Date: Wed, 29 Jun 2011 11:46:03 +0200
To: [email-masked], [email-masked]
Subject: Re: [fun] status of the homenet effort

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.=20

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.=20

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.=20

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.
>=20
> 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").
>=20
> 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.
>=20
> 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.
>=20
> 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).
>=20
> This is the most recent version of the charter we should discuss:
>=20
> Home Networks (homenet)
> -----------------------------------
>=20
> Current Status: Proposed
> Last Edit: Wednesday, June 29th, 2011
>=20
> Chairs:
> TBD
>=20
> Internet Area Directors:
> Ralph Droms <[email-masked]>
> Jari Arkko <[email-masked]>
>=20
> Internet Area Advisor:
> Jari Arkko <[email-masked]>
>=20
> Routing Area Technical Advisor:
> TBD
>=20
> Security Area Technical Advisor:
> TBD
>=20
> Mailing Lists:
> General Discussion: [email-masked]
> To Subscribe: https://www.ietf.org/mailman/listinfo/fun
> Archive: http://www.ietf.org/mail-archive/web/fun
>=20
> Description of Working Group:
>=20
> This working group focuses on the evolving networking technology
> within and among relatively small =93residential home=94 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:
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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:
>=20
> o prefix configuration for routers
> o managing routing
> o name resolution
> o service discovery
> o network security
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> Milestones:
>=20
> 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
>=20
> _______________________________________________
> fun mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/fun

Date: Wed, 29 Jun 2011 10:35:27 +0200
From: Jari Arkko <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [fun] status of the homenet effort

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

Date: Wed, 29 Jun 2011 09:46:20 +0200
From: Jari Arkko <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [fun] Any signs of life here?

Paul,

> It looks like the BoF is scheduled (under then name "homenet") for Quebec. However, the charter discussion seems to have fizzled out. Just wondering...
>   

There has been quite a bit of discussion, though unfortunately some of 
that has been on the IESG/IAB lists, and only some here. We should move 
all the discussion here (and we have, as you can see from some later posts).

Jari

Date: Wed, 29 Jun 2011 09:35:36 +0200
From: Jari Arkko <[email-masked]>
To: Mark Townsley <[email-masked]>,  Spencer Dawkins <[email-masked]>
Cc: [email-masked], 'IAB' <[email-masked]>, 'IESG' <[email-masked]>, [email-masked]
Subject: Re: [fun] [ipdir] [IAB] Revised homenet charter for IESG	consideration

Spencer, Mark: Agreed. I have made this change to the current copy of 
the charter. Thanks.

Jari

Date: Wed, 29 Jun 2011 09:30:17 +0200
From: Jari Arkko <[email-masked]>
To: Mark Townsley <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, IAB <[email-masked]>, IESG <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [fun] Revised homenet charter for IESG consideration

Randy, Mark, et al -- I agree about the without active administration 
part, of course. But was there a change in the charter text that you 
wanted based on this exchange?

Jari

Mark Townsley kirjoitti:
> On Jun 28, 2011, at 4:06 PM, Randy Turner wrote:
>
>   
>> "without active administration" should probably be the goal regardless of topology..,
>>     
>
> +1
>
> - Mark
>
>   

From: Ralph Droms <[email-masked]>
Date: Tue, 28 Jun 2011 10:41:21 -0400
To: Spencer Dawkins <[email-masked]>
Cc: [email-masked], IAB IAB <[email-masked]>, IESG IESG <[email-masked]>, [email-masked]
Subject: Re: [fun] [IAB]  Revised homenet charter for IESG consideration

On Jun 28, 2011, at 10:34 AM 6/28/11, Mark Townsley wrote:

>=20
> Thanks Spencer. For my part, I have no problem with your proposed =
text.

Fine with me, too...

- Ralph

>=20
> - Mark
>=20
> On Jun 28, 2011, at 4:23 PM, Spencer Dawkins wrote:
>=20
>> Dear INT ADs,
>>=20
>> I don't want to interrupt the food fight just to ask someone to pass =
the salt, but ... :D
>>=20
>> The current (last I saw) proposed charter for HOMENET didn't seem =
quite clear enough that having "as few subnets as possible" doesn't make =
the complexity of having multiple subnets go away. I was hoping that =
this could be stated a little more bluntly.
>>=20
>> Could I suggest something like
>>=20
>> OLD: 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,
>> incorporation of dedicated segments remain necessary for some
>> cases. For instance, ... (excellent reasons deleted because I wasn't =
questioning them)
>>=20
>> NEW: 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, ... (excellent =
reasons remain unchanged)
>>=20
>> I hope this is a helpful comment, because I don't want to derail the =
general conversation by saying something NOT helpful.
>>=20
>> Spencer=20
>> _______________________________________________
>> fun mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/fun
>=20

From: Mark Townsley <[email-masked]>
Date: Tue, 28 Jun 2011 16:38:35 +0200
To: Randy Turner <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, IAB <[email-masked]>, IESG <[email-masked]>
Subject: Re: [fun] Revised homenet charter for IESG consideration

On Jun 28, 2011, at 4:06 PM, Randy Turner wrote:

> "without active administration" should probably be the goal regardless =
of topology..,

+1

- Mark

>=20
> Randy
>=20
> On Jun 28, 2011, at 3:16 AM, Ralph Droms <[email-masked]> wrote:
>=20
>>=20
>> On Jun 27, 2011, at 1:52 PM 6/27/11, David Harrington wrote:
>>> [...]
>>> This sounds more like the description of an IRTF RG than an IETF WG.
>>> The ***engineering*** apparently is not yet clearly understood, and
>>> the "specific protocol work described below" is not at all specific.
>>=20
>> [...] with the major constraint that a simple network of a few links =
and routers has to operate with active admin intervention.
>>=20
>> s/with active admin intervention/without active admin intervention/
>>=20
>> - Ralph
>>=20
>>=20
>>=20
>> _______________________________________________
>> fun mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/fun
>>=20
> _______________________________________________
> fun mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/fun

From: Mark Townsley <[email-masked]>
Date: Tue, 28 Jun 2011 16:34:03 +0200
To: "Spencer Dawkins" <[email-masked]>
Cc: [email-masked], 'IAB' <[email-masked]>, 'IESG' <[email-masked]>, [email-masked]
Subject: Re: [fun] [IAB]  Revised homenet charter for IESG consideration

Thanks Spencer. For my part, I have no problem with your proposed text.

- Mark

On Jun 28, 2011, at 4:23 PM, Spencer Dawkins wrote:

> Dear INT ADs,
>=20
> I don't want to interrupt the food fight just to ask someone to pass =
the salt, but ... :D
>=20
> The current (last I saw) proposed charter for HOMENET didn't seem =
quite clear enough that having "as few subnets as possible" doesn't make =
the complexity of having multiple subnets go away. I was hoping that =
this could be stated a little more bluntly.
>=20
> Could I suggest something like
>=20
> OLD: 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,
> incorporation of dedicated segments remain necessary for some
> cases. For instance, ... (excellent reasons deleted because I wasn't =
questioning them)
>=20
> NEW: 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, ... (excellent =
reasons remain unchanged)
>=20
> I hope this is a helpful comment, because I don't want to derail the =
general conversation by saying something NOT helpful.
>=20
> Spencer=20
> _______________________________________________
> fun mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/fun

From: Ralph Droms <[email-masked]>
Date: Tue, 28 Jun 2011 10:30:12 -0400
To: Randy Turner <[email-masked]>
Cc: [email-masked], IAB IAB <[email-masked]>, IESG IESG <[email-masked]>, [email-masked]
Subject: Re: [fun] Revised homenet charter for IESG consideration

On Jun 28, 2011, at 10:06 AM 6/28/11, Randy Turner wrote:

> "without active administration" should probably be the goal regardless =
of topology..,

Obscure wording on my part.  What I was trying to express was, in fact, =
homenet should do its work within two independent constraints:

* simple network of a few links and routers
* operates without active admin intervention

- Ralph

>=20
> Randy
>=20
> On Jun 28, 2011, at 3:16 AM, Ralph Droms <[email-masked]> wrote:
>=20
>>=20
>> On Jun 27, 2011, at 1:52 PM 6/27/11, David Harrington wrote:
>>> [...]
>>> This sounds more like the description of an IRTF RG than an IETF WG.
>>> The ***engineering*** apparently is not yet clearly understood, and
>>> the "specific protocol work described below" is not at all specific.
>>=20
>> [...] with the major constraint that a simple network of a few links =
and routers has to operate with active admin intervention.
>>=20
>> s/with active admin intervention/without active admin intervention/
>>=20
>> - Ralph
>>=20
>>=20
>>=20
>> _______________________________________________
>> fun mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/fun
>>=20

From: "Spencer Dawkins" <[email-masked]>
To: <[email-masked]>, "'IAB'" <[email-masked]>, "'IESG'" <[email-masked]>, <[email-masked]>
Date: Tue, 28 Jun 2011 09:23:53 -0500
Subject: Re: [fun] [IAB]  Revised homenet charter for IESG consideration

Dear INT ADs,

I don't want to interrupt the food fight just to ask someone to pass the 
salt, but ... :D

The current (last I saw) proposed charter for HOMENET didn't seem quite 
clear enough that having "as few subnets as possible" doesn't make the 
complexity of having multiple subnets go away. I was hoping that this could 
be stated a little more bluntly.

Could I suggest something like

OLD: 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,
incorporation of dedicated segments remain necessary for some
cases. For instance, ... (excellent reasons deleted because I wasn't 
questioning them)

NEW: 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, ... (excellent reasons remain unchanged)

I hope this is a helpful comment, because I don't want to derail the general 
conversation by saying something NOT helpful.

Spencer 

From: Randy Turner <[email-masked]>
Date: Tue, 28 Jun 2011 07:06:34 -0700
To: Ralph Droms <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, IAB <[email-masked]>, IESG <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [fun] Revised homenet charter for IESG consideration

"without active administration" should probably be the goal regardless of to=
pology..,

Randy

On Jun 28, 2011, at 3:16 AM, Ralph Droms <[email-masked]> wrote:

>=20
> On Jun 27, 2011, at 1:52 PM 6/27/11, David Harrington wrote:
>> [...]
>> This sounds more like the description of an IRTF RG than an IETF WG.
>> The ***engineering*** apparently is not yet clearly understood, and
>> the "specific protocol work described below" is not at all specific.
>=20
> [...] with the major constraint that a simple network of a few links and r=
outers has to operate with active admin intervention.
>=20
> s/with active admin intervention/without active admin intervention/
>=20
> - Ralph
>=20
>=20
>=20
> _______________________________________________
> fun mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/fun
>=20

From: Ralph Droms <[email-masked]>
Date: Tue, 28 Jun 2011 06:16:41 -0400
To: "David Harrington" <[email-masked]>
Cc: [email-masked], 'IAB' <[email-masked]>, 'IESG' <[email-masked]>, [email-masked]
Subject: Re: [fun] Revised homenet charter for IESG consideration

On Jun 27, 2011, at 1:52 PM 6/27/11, David Harrington wrote:
> [...]
> This sounds more like the description of an IRTF RG than an IETF WG.
> The ***engineering*** apparently is not yet clearly understood, and
> the "specific protocol work described below" is not at all specific.

[...] with the major constraint that a simple network of a few links and =
routers has to operate with active admin intervention.

s/with active admin intervention/without active admin intervention/

- Ralph

Date: Tue, 28 Jun 2011 00:52:48 +0200
From: Jari Arkko <[email-masked]>
To: David Harrington <[email-masked]>
Cc: [email-masked], 'IAB' <[email-masked]>, 'IESG' <[email-masked]>, [email-masked]
Subject: Re: [fun] Revised homenet charter for IESG consideration

David,

> I think work on home networking standards is very important, and
> strongly support the effort.
> A little guidance on how I think this charter can be improved.
>   

Great!

> >From the 110623 version, 
> "Specific protocol work described below is anticipated to be within 
> the scope of the working group. However,
> the group is required to review its charter and milestones with the
> IESG and IETF community before submitting documents that make protocol
> changes."
>
> "anticipated to be within the scope" is very unclear as to what is or
> is not in scope.
> Is that "anticipated to be within the scope" AFTER a re-charter, and
> thus is NOT NOW is scope of this charter?
>   

After the recharter. I can clarify this. And it already says what 
specifically is not in scope (submitting documents that make protocol 
changes). How about this:

OLD:
Specific protocol work described below
is anticipated to be within the scope of the working group. However,
the group is required to review its charter and milestones with the
IESG and IETF community before submitting documents that make protocol
changes.
NEW:
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.

Would this be clearer?

> or is that "anticipated to be within the scope", so WG members can
> interpret it as being in scope NOW?
>
> My concern, and the concern of others, was that the original charter
> was too open-ended and did not provide for IETF review of the
> architecture and the potential changes it might drive before the WG
> was chartered to make such changes. This left  potentially important,
> and possibly bad, changes in protocols to be caught in IETF Last Call
> or IESG Evaluation, rather than in a review of the proposed protocol
> work during the chartering process.
>   

Right. I was one of those ADs who balloted against the charter back 
then. But lets focus on the current charter. I don't think this issue 
exists in the current charter as written.

> The charter text makes it obvious that the engineering changes are not
> yet clearly understood: 
>   

That's right. There's some work to be done. And given your comments from 
a couple of IESG meetings ago, we've changed the charter so that the 
architecture and plan for changes needs to come first. Once it is clear, 
the group can proceed for real with the changes.

> "The architecture document should drive what protocols changes, if
> any, are necessary."
> "existing protocols are likely sufficient, and at worst may need some
> small enhancements, ..."
> "it is expected that existing routing protocols can be used as is,
> however, a new mechanism may be needed ..."
> "The main goal of this [security] work is to enable a security policy
> that adapts to IPv6 threats as they emerge,..."
>
> This sounds more like the description of an IRTF RG than an IETF WG.
> The ***engineering*** apparently is not yet clearly understood, and
> the "specific protocol work described below" is not at all specific.
>   

I think we need to distinguish engineering efforts with a priori known 
end result (build this house) from those with more initial effort on 
requirements (build the optimal house for this family) and from research 
(develop new materials technology for houses). HOMENET is of the second 
type. In general, the IETF does not work only on the first type of 
efforts. We do constrain (and sometimes over- or under-constrain) 
efforts based on specific concerns, of course. The method that we're 
using in this case is to have the scope of solutions work decided by the 
IESG/IETF only after the architecture is clear. Continuing with the 
house construction analogy, this is like asking for the architects to 
make a plan for the house before committing to materials and 
construction contracts. However, just like with architecture, materials 
choices and technology has to be discussed as part of the architectural 
design, as they drive what can be built.

> a resulting architecture document needs to be clear
> about what specific engineering work is needed, and a subsequent
> re-charter should be clear about the ***engineering*** work to be
> done.

I think that is the intent. Is there something missing from the current 
charter text with regards to this? It says:

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 ... and other existing 
components of the IPv6
architecture. The architecture document should drive what protocols
changes, if any, are necessary.

Jari

From: Ralph Droms <[email-masked]>
Date: Mon, 27 Jun 2011 17:07:20 -0400
To: "David Harrington" <[email-masked]>
Cc: [email-masked], 'IAB' <[email-masked]>, 'IESG' <[email-masked]>, [email-masked]
Subject: Re: [fun] Revised homenet charter for IESG consideration

On Jun 27, 2011, at 1:52 PM 6/27/11, David Harrington wrote:

> Hi,
>=20
> I think work on home networking standards is very important, and
> strongly support the effort.
> A little guidance on how I think this charter can be improved.

David - frankly, you have given advice that this effort should be moved =
to the IRTF.  I  see very little advice on how to improve the charter =
for the WG in the IETF.

> =46rom the 110623 version,=20
> "Specific protocol work described below is anticipated to be within=20
> the scope of the working group. However,
> the group is required to review its charter and milestones with the
> IESG and IETF community before submitting documents that make protocol
> changes."
>=20
> "anticipated to be within the scope" is very unclear as to what is or
> is not in scope.
> Is that "anticipated to be within the scope" AFTER a re-charter, and
> thus is NOT NOW is scope of this charter?
> or is that "anticipated to be within the scope", so WG members can
> interpret it as being in scope NOW?

Can this issue be fixed with a simple rewording:

  Specific protocol work described below is anticipated
  to be identified by the architecture document as areas
  of work to be chartered as within the scope of the
  working group.=20

> My concern, and the concern of others, was that the original charter

I'd like to hear directly from others about their concerns regarding
the current charter.

> was too open-ended and did not provide for IETF review of the
> architecture and the potential changes it might drive before the WG
> was chartered to make such changes. This left  potentially important,
> and possibly bad, changes in protocols to be caught in IETF Last Call
> or IESG Evaluation, rather than in a review of the proposed protocol
> work during the chartering process.

Do you still have this same concern about the *current* charter?

>=20
> The charter text makes it obvious that the engineering changes are not
> yet clearly understood:=20
> "The architecture document should drive what protocols changes, if
> any, are necessary."
> "existing protocols are likely sufficient, and at worst may need some
> small enhancements, ..."
> "it is expected that existing routing protocols can be used as is,
> however, a new mechanism may be needed ..."
> "The main goal of this [security] work is to enable a security policy
> that adapts to IPv6 threats as they emerge,..."
>=20
> This sounds more like the description of an IRTF RG than an IETF WG.
> The ***engineering*** apparently is not yet clearly understood, and
> the "specific protocol work described below" is not at all specific.

I strongly disagree with you here.  This charter represents engineering =
work exactly as intended by the IETF.  The WG is chartered to define an =
architecture, and then engineer a system to meet the requirements of =
that architecture using existing protocols as building blocks.  Making a =
home network work is clearly not a research problem.  We know what needs =
to be done, with the major constraint that a simple network of a few =
links and routers has to operate with active admin intervention.  The =
hard work in the architecture will be to bound the problem and get =
consensus on how many is "a few".  If anything, the charter should more =
strongly express the strength of its convictions and state explicitly =
that existing protocols will be used with as few extensions as possible. =
 Otherwise, I'm fine with the charter as written and am happy to approve =
it.

- Ralph

>=20
> If the engineering is not yet understood, then I think research needs
> to be done, and a resulting architecture document needs to be clear
> about what specific engineering work is needed, and a subsequent
> re-charter should be clear about the ***engineering*** work to be
> done.
>=20
> David Harrington
> Director, IETF Transport Area
> [email-masked] (preferred for ietf)
> [email-masked]
> +1 603 828 1401 (cell)
>=20
>=20
>=20
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On=20
>> Behalf Of Jari Arkko
>> Sent: Thursday, June 23, 2011 7:05 AM
>> To: IAB; IESG; [email-masked]
>> Subject: Revised homenet charter for IESG consideration
>>=20
>> Secretary (Bcced),
>>=20
>> Please start an internal review and place this charter for=20
>> consideration=20
>> for external review in today's IESG telechat. (We will not approve
> it=20
>> for external review today, it will take at least until next=20
>> week. But I=20
>> would like to discuss it anyway.)
>>=20
>> All,
>>=20
>> This charter has been revised per discussion from the BOF call last=20=

>> week. The biggest change is that the group is required to produce an
>=20
>> architecture document and then come back to the IESG/community to
> ask=20
>> for revising/confirming the rest of its charter. My plan is to
> create=20
>> the working group before Quebec City. Should that fail, the=20
>> backup plan=20
>> is to run a BOF. But I personally believe this is something=20
>> we could and=20
>> should charter now. I understand the concerns people raised=20
>> in the BOF=20
>> call and I'm hoping that this version has made some=20
>> significant progress=20
>> in resolving those concerns.
>>=20
>> Jari
>>=20
>> -----
>>=20
>> Home Networks (homenet)
>> -----------------------------------
>>=20
>> Current Status: Proposed
>> Last Edit: Friday, June 23rd, 2011
>>=20
>> Chairs:
>> TBD
>>=20
>> Internet Area Directors:
>> Ralph Droms <[email-masked]>
>> Jari Arkko <[email-masked]>
>>=20
>> Internet Area Advisor:
>> Jari Arkko <[email-masked]>
>>=20
>> Routing Area Technical Advisor:
>> TBD
>>=20
>> Security Area Technical Advisor:
>> TBD
>>=20
>> Mailing Lists:
>> General Discussion: [email-masked]
>> To Subscribe: https://www.ietf.org/mailman/listinfo/fun
>> Archive: http://www.ietf.org/mail-archive/web/fun
>>=20
>> Description of Working Group:
>>=20
>> 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:
>>=20
>> 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,
>> incorporation of dedicated segments remain 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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:
>>=20
>> o prefix configuration for routers
>> o managing routing
>> o name resolution
>> o service discovery
>> o network security
>>=20
>> The task of the group is to produce an architecture document=20
>> 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 anticipated to be within the scope of the working group. However,
>> the group is required to review its charter and milestones with the
>> IESG and IETF community before submitting documents that make
> protocol
>> changes.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> Milestones:
>>=20
>> 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=20
>> 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 2011 First WG draft on name resolution
>> Feb 2011 First WG draft on service discovery
>> Feb 2011 First WG draft on perimeter security
>> Feb 2012 Start of routing related work in the relevant routing area=20=

>> working group, if needed
>> Mar 2012 Submission of the prefix configuration draft to the IESG as
>=20
>> Standards Track RFC
>> Apr 2012 Submission of the routing draft to the IESG as=20
>> Informational RFC
>> Jun 2012 Submission of the name resolution draft to the IESG as=20
>> Standards Track RFC
>> Jun 2012 Submission of the service discovery draft to the IESG as=20
>> Standards Track RFC
>> Aug 2012 Submission of the perimeter security draft to the IESG as=20
>> Informational RFC
>>=20
>>=20
>=20
> _______________________________________________
> fun mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/fun

From: "David Harrington" <[email-masked]>
To: "'Jari Arkko'" <[email-masked]>, "'IAB'" <[email-masked]>, "'IESG'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Mon, 27 Jun 2011 13:52:21 -0400
Subject: Re: [fun] Revised homenet charter for IESG consideration

Hi,

I think work on home networking standards is very important, and
strongly support the effort.
A little guidance on how I think this charter can be improved.

>From the 110623 version, 
"Specific protocol work described below is anticipated to be within 
the scope of the working group. However,
the group is required to review its charter and milestones with the
IESG and IETF community before submitting documents that make protocol
changes."

"anticipated to be within the scope" is very unclear as to what is or
is not in scope.
Is that "anticipated to be within the scope" AFTER a re-charter, and
thus is NOT NOW is scope of this charter?
or is that "anticipated to be within the scope", so WG members can
interpret it as being in scope NOW?

My concern, and the concern of others, was that the original charter
was too open-ended and did not provide for IETF review of the
architecture and the potential changes it might drive before the WG
was chartered to make such changes. This left  potentially important,
and possibly bad, changes in protocols to be caught in IETF Last Call
or IESG Evaluation, rather than in a review of the proposed protocol
work during the chartering process.

The charter text makes it obvious that the engineering changes are not
yet clearly understood: 
"The architecture document should drive what protocols changes, if
any, are necessary."
"existing protocols are likely sufficient, and at worst may need some
small enhancements, ..."
"it is expected that existing routing protocols can be used as is,
however, a new mechanism may be needed ..."
"The main goal of this [security] work is to enable a security policy
that adapts to IPv6 threats as they emerge,..."

This sounds more like the description of an IRTF RG than an IETF WG.
The ***engineering*** apparently is not yet clearly understood, and
the "specific protocol work described below" is not at all specific.

If the engineering is not yet understood, then I think research needs
to be done, and a resulting architecture document needs to be clear
about what specific engineering work is needed, and a subsequent
re-charter should be clear about the ***engineering*** work to be
done.

David Harrington
Director, IETF Transport Area
[email-masked] (preferred for ietf)
[email-masked]
+1 603 828 1401 (cell)

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Jari Arkko
> Sent: Thursday, June 23, 2011 7:05 AM
> To: IAB; IESG; [email-masked]
> Subject: Revised homenet charter for IESG consideration
> 
> Secretary (Bcced),
> 
> Please start an internal review and place this charter for 
> consideration 
> for external review in today's IESG telechat. (We will not approve
it 
> for external review today, it will take at least until next 
> week. But I 
> would like to discuss it anyway.)
> 
> All,
> 
> This charter has been revised per discussion from the BOF call last 
> week. The biggest change is that the group is required to produce an

> architecture document and then come back to the IESG/community to
ask 
> for revising/confirming the rest of its charter. My plan is to
create 
> the working group before Quebec City. Should that fail, the 
> backup plan 
> is to run a BOF. But I personally believe this is something 
> we could and 
> should charter now. I understand the concerns people raised 
> in the BOF 
> call and I'm hoping that this version has made some 
> significant progress 
> in resolving those concerns.
> 
> Jari
> 
> -----
> 
> Home Networks (homenet)
> -----------------------------------
> 
> Current Status: Proposed
> Last Edit: Friday, June 23rd, 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,
> incorporation of dedicated segments remain 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 anticipated to be within the scope of the working group. However,
> the group is required to review its charter and milestones with the
> IESG and IETF community before submitting documents that make
protocol
> changes.
> 
> 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 2011 First WG draft on name resolution
> Feb 2011 First WG draft on service discovery
> Feb 2011 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
> Jun 2012 Submission of the name resolution draft to the IESG as 
> Standards Track RFC
> Jun 2012 Submission of the service discovery draft to the IESG as 
> Standards Track RFC
> Aug 2012 Submission of the perimeter security draft to the IESG as 
> Informational RFC
> 
> 

From: Paul Hoffman <[email-masked]>
Date: Sat, 25 Jun 2011 09:10:17 -0700
To: [email-masked]
Subject: [fun] Any signs of life here?

It looks like the BoF is scheduled (under then name "homenet") for =
Quebec. However, the charter discussion seems to have fizzled out. Just =
wondering...

--Paul Hoffman

From: "David Harrington" <[email-masked]>
To: "'Jari Arkko'" <[email-masked]>, <[email-masked]>
Date: Thu, 16 Jun 2011 11:54:04 -0400
Subject: Re: [fun] new version of the charter

Hi,

a few comments:
 
1) I think this proposal is obviously AD-shopping with roughly the
same proposal that was rejected last year, because the scope was too
open-ended.  

I notice the FUN mailng list has no discussions on it.

2) "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."
If you need a mechanism to turn it on, then it apparently is not on by
default.
Or it is on by default, but you need a mechanism for an administrator
to turn it on/off as desired.

3) "It is expected that the working group will define a set of
protocol
specifications to accomplish the five requirements from
above. ... Prefix configuration, routing, and security
related work shall not cause any changes that are not backwards
compatible to existing IPv6 hosts... The working group will liaise
with the relevant IETF working groups
and other standards bodies. "

I think this is way too open-ended. Can this WG modify security
protocol standards that have been developed in the security area? Can
it modify protocols TCP options without bother to go through the TCP
maintenece WG, which has been chartered to handle TCP maintenance
issues? This charter certainly does not constrain such things.

If the INT ADs want to allow a free-hand on modifying INT protocols,
that's their business (to a degree), and obviously the charter has
constraints on modification of INT protocols like DNS and DHCP. Giving
these guys free rein to modify any protocol they choose, apparently
from any area, seems over-reaching to me. I would be much more
accepting of a charter that said they could identify proposed
requirements and proposed changes to meet those requirements, but any
such changes to existing protocols would need to be done by WGs in the
appropriate area, or require a re-charter as deliverables for this WG
to develop. 

I raise this point partly because, for example, it is important to
keep TCP stable; but the TCPM WG gets (fairly) frequent requests to
modify or add TCP options. If any TCP option proposals might be
handled, I would want to know they go through the TCPM WG. If storage
were to be addressed, I would want the storage experts from NFS/STORM
involved. If a security protocol is going to be modified, I would want
to know that the security experts have a hand in the design to ensure
that the assumptions built into our current security standards .

I do not find the following sufficiently constraining "The working
group will liaise with the relevant IETF working groups
and other standards bodies." I think, at a minimum, the area
responsible for a protocol should be required to approve changes to
their area's protocols. And the recharter process is designed to make
sure that changes in WG direction are transparent, and that the IETF
as a whole has rough consensus on the proposed WG directions. The
charter as written seems to relieve the WG of the responsibility for
such transparency and IETF consensus.

4) Even the text that does constrain their work on routing apparently
gives them absolute control over the architecure and requirements: "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."
I would be happier with "with the HOMENET working group providing a
proposed architecture and proposed requirements for such
enhancements."

5) The HOMENET WG is mentioned in the charter. Is this proposed WG
going to be called HOMENET? or FUN?

6) The milestones aren't very specific.
"Oct 2011 First WG draft on the architecture"
	So is this WG going to define just one architecture that all
home networks are expected to use?
	Do the home architectures typically found in US home networks
match the architectures used in European home networks and Chinese
home networks and South Amrican home networks? My impression is the
relationship between ISPs and home users differ markedly between US
users and Chinese home users. Are we favoring a particular
architectural approach (and particular vendors) by defining one
architecture?
	Would it be more realistic to call this "an" architecture? Is
this really an appicability statement about the
	home network designs to which the other WG documents will
apply? and is that architecture vendor-neutral?
"Dec 2011 First WG draft on routing" and "Apr 2012 Submission of the
routing draft to the IESG as Informational RFC"
	What is going to be included in this draft? proposed routing
enhancements? proposed requirements?

7) If a similar open-ended charter were submitted to us by a proponent
of clouds, such as Bhumip, or a proponent from Huawei or China Mobile,
would we really approve such an open charter?  

8) To look beyond just the charter of a specific WG, there has been a
recent trend away from the Internet-stack approach,  reflected in the
IETF organization of INT/TSV/APP, toward a deployment/use-case and
multi-layer approach to development, reflected in recent barBOFs and
BOFs such as Clouds, data center, and home networking. Is this a
direction the IETF should be going? Should we change our
organizational structure (and possibly the architecture of the
Internet) to reflect this change in thinking? Since the IESG members
are the managers of the IETF standards process, should we be
developing process regarding cross-area work such as clouds, data
center, and home networking?

David Harrington
Director, IETF Transport Area
[email-masked] (preferred for ietf)
[email-masked]
+1 603 828 1401 (cell)

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Jari Arkko
> Sent: Thursday, June 16, 2011 1:16 AM
> To: [email-masked]
> Subject: [fun] new version of the charter
> 
> 
> Mark Townsley provided me with a suggested edit of the 
> charter. I think 
> it looks pretty good. Thoughts?
> 
> Home Networks (homenet)
> -----------------------------------
> 
> Current Status: Proposed
> Last Edit: Friday, June 16th, 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 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.
> 
> o Home networks are moving from a "one size fits all" model to
> incorporation of dedicated segments for specific purposes. For
> instance, a common feature in modern home routers in the ability to
> support both guest and private network segments. Similar needs for
> separation 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 and 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
and
> necessary additional tools addressing this full scope of
requirements:
> 
> o prefix configuration for routers
> 
> o managing routing
> 
> o name resolution
> 
> o service discovery
> 
> o network security
> 
> Specifically, the group will 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.
> 
> In addition, the group will apply existing protocols to handle the
> five requirements above. For prefix configuration, DHCPv6 PD is an
> obvious candidate solution, possibly supplemented by 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 are
> needed to mDNS and DNS-SD 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
> and other standards bodies. 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 get feedback on DNS issues from
> 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.
> 
> Milestones:
> 
> Oct 2011 First WG draft on the architecture
> Dec 2011 First WG draft on prefix configuration
> Dec 2011 First WG draft on routing
> Jan 2011 First WG draft on name resolution
> Feb 2011 First WG draft on service discovery
> Feb 2011 First WG draft on perimeter security
> Feb 2012 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
> Apr 2012 Submission of the routing draft to the IESG as 
> Informational RFC
> Jun 2012 Submission of the name resolution draft to the IESG as 
> Standards Track RFC
> Jun 2012 Submission of the service discovery draft to the IESG as 
> Standards Track RFC
> Aug 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
> 

Date: Thu, 16 Jun 2011 08:16:03 +0300
From: Jari Arkko <[email-masked]>
To: [email-masked]
Subject: [fun] new version of the charter

Mark Townsley provided me with a suggested edit of the charter. I think 
it looks pretty good. Thoughts?

Home Networks (homenet)
-----------------------------------

Current Status: Proposed
Last Edit: Friday, June 16th, 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 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.

o Home networks are moving from a "one size fits all" model to
incorporation of dedicated segments for specific purposes. For
instance, a common feature in modern home routers in the ability to
support both guest and private network segments. Similar needs for
separation 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 and 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 and
necessary additional tools addressing this full scope of requirements:

o prefix configuration for routers

o managing routing

o name resolution

o service discovery

o network security

Specifically, the group will 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.

In addition, the group will apply existing protocols to handle the
five requirements above. For prefix configuration, DHCPv6 PD is an
obvious candidate solution, possibly supplemented by 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 are
needed to mDNS and DNS-SD 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
and other standards bodies. 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 get feedback on DNS issues from
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.

Milestones:

Oct 2011 First WG draft on the architecture
Dec 2011 First WG draft on prefix configuration
Dec 2011 First WG draft on routing
Jan 2011 First WG draft on name resolution
Feb 2011 First WG draft on service discovery
Feb 2011 First WG draft on perimeter security
Feb 2012 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
Apr 2012 Submission of the routing draft to the IESG as Informational RFC
Jun 2012 Submission of the name resolution draft to the IESG as 
Standards Track RFC
Jun 2012 Submission of the service discovery draft to the IESG as 
Standards Track RFC
Aug 2012 Submission of the perimeter security draft to the IESG as 
Informational RFC

Date: Tue, 07 Jun 2011 18:25:59 +0300
From: Jari Arkko <[email-masked]>
To: Stephane Bortzmeyer <[email-masked]>
Cc: [email-masked]
Subject: Re: [fun] New Non-WG Mailing List: fun -- FUture home Networking (FUN)

Stephane,

>> For name resolution and service discovery, extensions are needed to
>> mDNS and DNS-SD to enable them to work across subnets.
>>     
>
> There is currently one RFC about, how to call it, "local name
> resolution", it is RFC 4795. Why mentioning only the other proposal?
>   

I think this is a bug in the charter. It should really cover both.

But I'm not the local name resolution expert. What do others think?

Jari

Date: Tue, 07 Jun 2011 18:24:37 +0300
From: Jari Arkko <[email-masked]>
To: [email-masked]
Subject: [fun] proposed charter

FUture home Networks (FUN)
-------------------------

Current Status: Proposed
Last Edit: Friday, June 3rd, 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 in
small networks such as those in homes. This evolution sets some
requirements on IETF protocols. An obvious trend for home networking
is the proliferation of networking technology in increasing number of
different devices, from home entertainment systems to appliances and
energy applications, just to name a few examples.  This leads to a
higher number of networked devices in each network.  However, some
more fundamental changes are occurring at the same time as well:

o  First, the link layer networking technology is become more
   heterogeneous, as networks are starting to employ, for instance,
   both traditional Ethernet technology and link layers designed for
   low-powered sensor networks.

o  Networks are also moving from a "one size fits all" model to
   dedicated segments for specific purposes. For instance, a common
   feature in high-end home routers in the ability to support both
   guest and private network segments. Similar needs for separation
   may occur in other cases, such as separating building control from
   the Internet access network. Typically, different subnets, routing
   and firewalls are used between the different segments.

o  Service providers are rolling out networks that support IPv6, and
   home gateway support for IPv6 is starting to appear. But for home
   networks, IPv6 is not just a new protocol, it also changes address
   allocation principles and allows end-to-end communication to the
   devices in the home.

o  End-to-end communication is both an opportunity and a problem, as it
   enables new applications but also exposes nodes in the internal
   networks to unwanted traffic from the Internet. Firewalls are in
   many cases needed to prevent exposure. However, this reduces the
   usefulness of end-to-end connectivity, as the firewall policy model
   is usually default deny, only allowing a small set of known
   protocols. In addition, consumer equipment typically reacts slowly
   if at all to changes in the typical Internet application, and it is
   likely that traffic for a popular application is not recognized by
   devices manufactured before that application was launched.

Future home networks need to provide the tools to handle these
situations in an easy manner. It is obvious that manual configuration
is rarely possible. For IPv4, NAT and private address based solutions
already provide limited solutions. The purpose of this working group
is to develop an architecture and necessary additional tools for IPv6,
to address the full scope of requirements:

o  prefix configuration for routers
o  managing routing (including turning it on by default)
o  name resolution
o  service discovery
o  perimeter security

Specifically, the group should 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.

In addition, the group will apply existing protocols to handle the
five requirements above. For prefix configuration, DHCPv6 PD is an
obvious candidate solution, possibly supplemented by 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.
For name resolution and service discovery, extensions are needed to
mDNS and DNS-SD to enable them to work across subnets.

For perimeter 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 default allow
security policy. This may be accomplished, for instance, through
driving security policy from an up-to-date database in the Internet or
using simple security along with firewall control protocols such as
PCP.

It is expected that the working group defines 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 visible to 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 working group will liaise with the relevant IETF working groups
and other standards bodies. 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 get feedback on DNS issues from
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 FUN working group
providing the architecture and requirements for such enhancements.

Milestones:

Oct 2011    First WG draft on the architecture
Dec 2011    First WG draft on prefix configuration
Dec 2011    First WG draft on routing
Jan 2011    First WG draft on name resolution
Feb 2011    First WG draft on service discovery
Feb 2011    First WG draft on perimeter security
Feb 2012    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
Apr 2012    Submission of the routing draft to the IESG as Informational RFC
Jun 2012    Submission of the name resolution draft to the IESG as 
Standards Track RFC
Jun 2012    Submission of the service discovery draft to the IESG as 
Standards Track RFC
Aug 2012    Submission of the perimeter security draft to the IESG as 
Informational RFC

Date: Tue, 7 Jun 2011 09:16:02 +0200
From: Stephane Bortzmeyer <[email-masked]>
To: Jari Arkko <[email-masked]>
Organization: NIC France
Cc: [email-masked]
Subject: Re: [fun] New Non-WG Mailing List: fun -- FUture home Networking (FUN)

On Tue, Jun 07, 2011 at 08:01:48AM +0300,
 Jari Arkko <[email-masked]> wrote 
 a message of 164 lines which said:

> For name resolution and service discovery, extensions are needed to
> mDNS and DNS-SD to enable them to work across subnets.

There is currently one RFC about, how to call it, "local name
resolution", it is RFC 4795. Why mentioning only the other proposal?

Date: Mon, 6 Jun 2011 22:47:55 +0200
From: Stephane Bortzmeyer <[email-masked]>
To: IETF Secretariat <[email-masked]>
Organization: NIC France
Cc: [email-masked], [email-masked]
Subject: Re: [fun] New Non-WG Mailing List: fun -- FUture home Networking (FUN)

On Mon, Jun 06, 2011 at 09:54:56AM -0700,
 IETF Secretariat <[email-masked]> wrote 
 a message of 15 lines which said:

> Purpose: Mailing list for proposed working group on FUture home Networking (FUN)

And nothing more (same thing on the Web site). Could we ask for a
little bit more context when a new IETF list is created?

From: IETF Secretariat <[email-masked]>
To: IETF Announcement list <[email-masked]>
Date: Mon,  6 Jun 2011 09:54:56 -0700 (PDT)
Cc: [email-masked]
Subject: [fun] New Non-WG Mailing List: fun -- FUture home Networking (FUN)

A new IETF non-working group email list has been created.

List address: [email-masked]
Archive: http://www.ietf.org/mail-archive/web/fun/
To subscribe: https://www.ietf.org/mailman/listinfo/fun

Purpose: Mailing list for proposed working group on FUture home Networking (FUN)

For additional information, please contact the list administrators.

Content-class: urn:content-classes:message
Date: Fri, 1 Jul 2011 00:30:14 -0500
From: "JP Vasseur (jvasseur)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [fun] [homegate] HOMENET working group proposal

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

On Jun 30, 2011, at 5:46 PM, Keith Moore wrote:

>=20
> On Jun 30, 2011, at 5:57 AM, Mark Townsley wrote:
>=20
>>=20
>> 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:
>>=20
>> - 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
>=20
> 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.

Yes, and I think that IPv6 should naturally do a better job than IPv4 in =
the cases where it can.=20

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.

- Mark

>=20
> IPv4 is a dinosaur gasping for its last breaths.
>=20
> Keith
>=20
>=20
> _______________________________________________
> homegate mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homegate

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

Content-class: urn:content-classes:message
Date: Fri, 1 Jul 2011 00:27:21 -0500
From: "JP Vasseur (jvasseur)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [fun] status of the homenet effort

I also think that this deals with an important topic and the list of =
items listed on the proposed charter are quite relevant. I'm just not =
entirely clear on the "routing component": are you referring to:
* A requirement document for Routing in the home?
* A recommendation for a specific routing protocol ?
* A framework before the specification of a new routing protocol ?
I'm clearly not expressing an opinion, just a question.
Thanks.
JP.

JP Vasseur
Cisco Fellow

Sent from Blackberry

----- Original Message -----
From: Mark Townsley [mailto:[email-masked]]
Sent: Thursday, June 30, 2011 11:36 AM
To: Weil, Jason <[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [fun] status of the homenet effort

Thank you for the feedback, keep it coming.

On Jun 30, 2011, at 4:14 PM, Weil, Jason wrote:

> Mark, Raplh, Jari, et all,
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> FWIW, I would also add that the five topics in the charter are also =
listed
> in order
> Of priority at least for me.
>=20
>=20
> Thanks,
>=20
> Jason
>=20
>=20
> On 6/29/11 5:46 AM, "Mark Townsley" <[email-masked]> wrote:
>=20
>>=20
>> All,
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> Thanks, and see you on the list and in Quebec.
>>=20
>> - Mark
>>=20
>>=20
>> On Jun 29, 2011, at 10:35 AM, Jari Arkko wrote:
>>=20
>>> I wanted to provide an update of the situation with this working =
group
>>> proposal.
>>>=20
>>> 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").
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> 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).
>>>=20
>>> This is the most recent version of the charter we should discuss:
>>>=20
>>> Home Networks (homenet)
>>> -----------------------------------
>>>=20
>>> Current Status: Proposed
>>> Last Edit: Wednesday, June 29th, 2011
>>>=20
>>> Chairs:
>>> TBD
>>>=20
>>> Internet Area Directors:
>>> Ralph Droms <[email-masked]>
>>> Jari Arkko <[email-masked]>
>>>=20
>>> Internet Area Advisor:
>>> Jari Arkko <[email-masked]>
>>>=20
>>> Routing Area Technical Advisor:
>>> TBD
>>>=20
>>> Security Area Technical Advisor:
>>> TBD
>>>=20
>>> Mailing Lists:
>>> General Discussion: [email-masked]
>>> To Subscribe: https://www.ietf.org/mailman/listinfo/fun
>>> Archive: http://www.ietf.org/mail-archive/web/fun
>>>=20
>>> Description of Working Group:
>>>=20
>>> This working group focuses on the evolving networking technology
>>> within and among relatively small =B3residential home=B2 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:
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> 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:
>>>=20
>>> o prefix configuration for routers
>>> o managing routing
>>> o name resolution
>>> o service discovery
>>> o network security
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> Milestones:
>>>=20
>>> 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
>>>=20
>>> _______________________________________________
>>> fun mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/fun
>>=20
>> _______________________________________________
>> fun mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/fun
>=20
>=20
> 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.

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

From: Martin Focazio <[email-masked]>
Date: Thu, 30 Jun 2011 21:34:10 -0400
To: james woodyatt <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [fun] [homegate]  HOMENET working group proposal

On Jun 30, 2011, at 19:51, james woodyatt <[email-masked]> wrote:

>
> The key thing here is that by Alice choosing to use one service provider =
over another, she can make Bob's application fail, and vice versa.  The mob=
ile service providers that don't have enough IPv4 addresses to serve all th=
eir customers are in a bind and can't budge.  The wireline service provider=
s who have 5-10 years of IPv4 addresses in reserve are the ones whistling p=
ast the graveyard.
>

You assume at Alice CAN select a service provider. In a large part of
the USA your choices are nil. You have a single wireline provider or
you don't have a connection.