Subject: Re: [fun] WG Review: Home Networks (homenet)
From: Keith Moore <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Tue, 5 Jul 2011 13:18:21 -0400
List-Id: "FUture home Networking \(FUN\)" <fun.ietf.org>

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

it seems like host/device security, as distinguished from network security, should also be in this list.

ease of configuration would appear to be paramount, and this touches on the interface between hosts/devices and the home network, particularly any perimeter based security mechanisms.  I'm thinking that when someone gets a new device, they might need to "pair" it with their network (similar to Bluetooth devices) so that the perimeter security devices know to allow traffic for it (and what kinds of traffic to allow).  similarly, hosts which have permission to access such devices from outside of the home network might also need to be "paired". 

one of the questions that I have is: to what extent is it reasonable to expect that network-accessible devices made for use in homes (and hosts that talk to them) are different than network-accessible devices used in other environments (and the hosts that talk to them)?  offhand I'm thinking that you want to be able to support ordinary hosts, devices, and applications on home networks, but it might take a bit more work to get their traffic through perimeter security.  similarly, you want to be able to enable ordinary hosts to talk to things on the home network, but doing so might be more cumbersome than for hosts with the appropriate support built-in.   there are multiple approaches for external access that could be considered: proxies, IPsec, tunnels, etc.  one thing that should be clear up front, is that using ip addresses for authentication tokens is a bad idea, no matter how widespread the practice is.

I guess I think that there's a real need to develop a standard means to arrange for secure external access to internal devices that are granted permission for such access.

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

I don't think it should be presumed that ULA's are applicable.  Perhaps, but not certainly.  ULAs should be limited to devices for which there is never any need to be accessed from outside the network, or to access external hosts, and offhand I can't think of a situation that makes it reasonable to impose this limitation on every device on a network segment..  If ULAs can be doled out to only those devices that do not have permission for external access, independent of network segment, that might be fine. 

Keith

From: IESG Secretary <[email-masked]>
To: IETF Announcement list <[email-masked]>
Date: Tue,  5 Jul 2011 09:35:28 -0700 (PDT)
Cc: [email-masked]
Subject: [fun] WG Review: Home Networks (homenet)
Reply-To: [email-masked]

A new IETF working group has been proposed in the Internet Area.  The 
IESG has not made any determination as yet. The following draft charter 
was submitted, and is provided for informational purposes only. Please 
send your comments to the IESG mailing list ([email-masked]) by Tuesday, 
July 12, 2011.                              

Home Networks (homenet)
-----------------------------------
Current Status: Proposed Working Group
Last Edit: Thursday, 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: Mon, 4 Jul 2011 08:33:00 -0400
To: Kenneth Voort <[email-masked]>
Cc: [email-masked], Doug Barton <[email-masked]>
Subject: Re: [fun] [homegate] HOMENET working group proposal

On Jul 3, 2011, at 4:29 PM, Kenneth Voort wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 11-07-02 9:31 PM, Doug Barton wrote:
>> On 07/01/2011 14:17, Keith Moore wrote:
>>> On Jul 1, 2011, at 4:13 PM, Doug Barton wrote:
>>> 
>>>> This is an area that we very clearly do not need to get involved in
>>>> because it will solve itself due to market forces. Right now there
>>>> is no IPv6-only content that anyone cares about. When that changes,
>>>> users will start demanding that their provider give them access to
>>>> it, or vote with their feet.
> When that happens, the end-to-end (or perhaps site-to-site) model of the Internet will be broken. I
> would argue that the Internet is more about "reachability" than "content" or "conversation". When
> the day comes when it is no longer technically possible to reach any Internet-connected host who
> wants me to reach it, from anywhere, the Internet will be broken. While IPv6 has the promise to fix
> a great many things, it also carries with it the threat of breaking that fundamental assumption upon
> which the Internet is built.

Maybe I'm missing something.  How does IPv6 threaten that model?  

If what you're worried about is that IPv4 and IPv6 can't talk to each other: My take is that there will be considerable economic pressure to reduce support costs associated with IPv4 once IPv6 support is widespread.  And I don't actually believe there will be any significant amount of "content" that will be accessible only via IPv6 until 99% of Internet users have IPv6.  

(There may well be applications that only work with IPv6 long before that.  But unless there's some easy, general way to run IPv6 over IPv4 that works pretty much everywhere, those applications will be limited to niche markets.)

People didn't stop sending email just because BITNET fell into disuse.  They just switched to using Internet email addresses.

Keith

Date: Mon, 4 Jul 2011 14:13:20 +0900
From: Erik Kline <[email-masked]>
To: james woodyatt <[email-masked]>
Cc: [email-masked]
Subject: Re: [fun] [homegate] HOMENET working group proposal

> I suspect it wouldn't take much to adapt 6RD to these ends.  Remember, 6RD tunnels do *not* need to be terminated by the provider network.  They can be terminated by a third-party with minimal human interface burden.  Perhaps I should find the time to write a draft on the topic.

+1

This plus the idea of being able to map a public v6 address to an
internal IPv4 address (the home gateway does the address family
translation) and folks could have all manner of broader access that
just what portmapping allows.

If the mechanism could resync and adjust accordingly when the public
IPv4 address changes (probably involving dyndns.org-like updates),
then why not have multiple named webservers running at home (all on
v6, port 80)?

Things get more complicated if there's a CGN in the picture, but that
could be addressed by separate efforts.

From: Joel Jaeggli <[email-masked]>
Date: Sun, 3 Jul 2011 16:22:22 -0700
To: [email-masked]
Cc: [email-masked]
Subject: Re: [fun] status of the homenet effort

On Jul 1, 2011, at 3:14 PM, Robert Raszuk wrote:

> Hi Jari,
> 
>> As Mark noted, some aspects of diagnostics and troubleshooting are
>> inherent in the notion of automatic configuration. Prefix delegation,
>> routing, etc. has to figure out if there is connectivity and what to do
>> if there isn't. But its mostly automatic, not built for human network
>> managers to play with.
> 
> Well honestly while I agree that automation is great for vast majority of home networks, unfortunately for someone like me it is just scary - maybe too scary. If I buy or rent a car I always pick manual ... (maybe wrong comparison maybe not ... but it is just a matter of awareness of one's skills of control).

If it doesn't work without intervention by the user, then the solution adopted by the vendor will  definitely not be compliant with the specification. The condition of not requiring intervention is essentially cooked in the the commercial acceptance of products in the space.

Date: Sun, 03 Jul 2011 16:29:17 -0400
From: Kenneth Voort <[email-masked]>
To: [email-masked]
Cc: Doug Barton <[email-masked]>, Keith Moore <[email-masked]>
Subject: Re: [fun] [homegate] HOMENET working group proposal

On 11-07-02 9:31 PM, Doug Barton wrote:
> On 07/01/2011 14:17, Keith Moore wrote:
>> On Jul 1, 2011, at 4:13 PM, Doug Barton wrote:
>>
>>> This is an area that we very clearly do not need to get involved in
>>> because it will solve itself due to market forces. Right now there
>>> is no IPv6-only content that anyone cares about. When that changes,
>>> users will start demanding that their provider give them access to
>>> it, or vote with their feet.
When that happens, the end-to-end (or perhaps site-to-site) model of the Internet will be broken. I
would argue that the Internet is more about "reachability" than "content" or "conversation". When
the day comes when it is no longer technically possible to reach any Internet-connected host who
wants me to reach it, from anywhere, the Internet will be broken. While IPv6 has the promise to fix
a great many things, it also carries with it the threat of breaking that fundamental assumption upon
which the Internet is built.

>> Whenever people talk about the Internet as if it were just about
>> "access to content", I have to wonder.    The Internet has always
>> been more about conversation than content.
> 
> The overwhelming majority of Internet users are consumers of content. Some of that content is stuff
> like Skype, instant messaging, etc.
> 
> The overwhelming majority of businesses that make the Internet work are the content providers, and
> the ISPs that enable the consumers of that content to reach it.
> 
> Failure to recognize these 2 critical facts leads to producing standards documents that have no
> relevance in the real world.

I agree with you to a point. Where I see a problem is in *new* content producers coming online. It's
not possible anymore for there to be another service provider such as YouTube or Netflix, or for
that matter another ISP like Comcast or BT, with the IPv4 space there is left. Until and unless we
see massive IPv6 deployment we're stuck with the players we've got. Nobody's going to build another
Netflix and just wait for the ISP's to get the users to them. The transition should be engineered,
not simply left to existing market forces to evolve.
> 
>>> To summarize my main point once again, there is nothing for the
>>> IETF to do here, the problem will take care of itself.
>>
>> Quite the contrary.  We still don't have a good transition mechanism
>> that HOMENET could specify.
> 
> And as I pointed out in the bits of my message that you snipped, we don't need one.
> 
> 
> Doug

Perhaps, perhaps not. But I do think the behavior of an IPv6 network/host/CPE in the absence of IPv6
connectivity, or where not all of [more than one] providers is IPv6, should be defined, at the
least. We will otherwise see some surely unpredictable and incompatible behavior. Should it be
assumed that the only IPv6 provider must therefore be the default IPv6 route? What if that provider
is the power company? Or should a default IPv6 route *always* be established via the same interface
as the default IPv4 route? Should home networks establish IPv6 connectivity where none exists?

I would also argue that some method of reaching the IPv6 Internet without provider-supplied IPv6
should be considered and/or recommended. Is it within HOMENET's scope to /encourage/ IPv6
deployment, or merely /facilitate/ it?

We agree that there will be a day when not every host on the Internet will be reachable from every
other host. I think what we disagree on is the scope and severity of the problem, and when it will
happen. It is my hope that most people never hear the term "IPv6".

- -- 
Kenneth Voort - kenneth {at} voort <SPAMGUARD> {dot} ca
FDF1 6265 EBAB C05C FD06 1AED 158E 14D6 37CD E87F | pgp encrypted email preferred

From: Cullen Jennings <[email-masked]>
Date: Sat, 2 Jul 2011 23:54:07 -0600
To: Fred Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [fun] Routing ?

On Jul 2, 2011, at 9:29 PM, Fred Baker wrote:

> 
> On Jul 1, 2011, at 5:24 PM, Cullen Jennings wrote:
> 
>> I'm sure this is a spectacularly clueless question but, .... could someone say a bit more about why we need a routing protocol.
> 

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

> Well, if you draw a circle around the network so small that it consists of exactly one router (figure 2 of draft-baker-fun-multi-router), I guess we don't. However, I'll note that (discussion on v6ops a few months back) existing IPv4 residential gateways for the most part support a routing protocol - usually RIPv2. If present residential gateways have that requirement for market reasons, it does seem reasonable to expect future ones to.
> 
> I guess the question I would ask is not "why", but "given that there is evidently a present market requirement, why not". Can you explain to me why every residential gateway manufacturer save one - including Linksys - is wrong?

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

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

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

From: Keith Moore <[email-masked]>
Date: Sat, 2 Jul 2011 23:43:49 -0400
To: Doug Barton <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [fun] [homegate] HOMENET working group proposal

On Jul 2, 2011, at 9:31 PM, Doug Barton wrote:

> On 07/01/2011 14:17, Keith Moore wrote:
>> 
>> 
>> Whenever people talk about the Internet as if it were just about
>> "access to content", I have to wonder.    The Internet has always
>> been more about conversation than content.
> 
> The overwhelming majority of Internet users are consumers of content. Some of that content is stuff like Skype, instant messaging, etc.

The point is that the Internet is not primarily about producers in the center doling out content to users at the edge.  Granted, netflix uses a lot of bandwidth.  But a lot of what has driven use of the Internet, and continues to drive it, is users engaging in conversation of one form or another.  This was true when email and Usenet were the apps consuming the most bandwidth, and it's true today for Skype, Facebook, Youtube, IM, blogs, etc.

Meanwhile, traditional producer-to-consumer media channels of all types are steadily dying.   They tend to blame it on copyright violation, or "free" access to content on the Internet.  The real problem is that most of what they produce is crap.  They're stuck in an old model that says that a few people should decide what's good for everybody else, but now people are in a position to decide what's good for themselves and/or create their own content.

> The overwhelming majority of businesses that make the Internet work are the content providers, and the ISPs that enable the consumers of that content to reach it.
> 
> Failure to recognize these 2 critical facts leads to producing standards documents that have no relevance in the real world.

Insistence on sticking to anachronistic models of "the real world" will do the same thing.   

Keith

From: Fred Baker <[email-masked]>
Date: Sat, 2 Jul 2011 20:29:45 -0700
To: Cullen Jennings <[email-masked]>
Cc: [email-masked]
Subject: Re: [fun] Routing ?

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

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

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

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

Date: Sat, 02 Jul 2011 18:31:47 -0700
From: Doug Barton <[email-masked]>
Organization: http://SupersetSolutions.com/
To: Keith Moore <[email-masked]>
OpenPGP: id1ABC84
Cc: [email-masked], [email-masked]
Subject: Re: [fun] [homegate] HOMENET working group proposal

On 07/01/2011 14:17, Keith Moore wrote:
> On Jul 1, 2011, at 4:13 PM, Doug Barton wrote:
>
>> On 07/01/2011 13:03, Kenneth Voort wrote:
>>> I would also add that future IPv6 capable devices should allow
>>> end users to reach the IPv6 Internet from an IPv4-only provider
>>> through some means, perhaps tunneling, with no or minimal
>>> administrator intervention. I can see many providers remaining
>>> IPv4-only long into the future.
>>
>> This is an area that we very clearly do not need to get involved in
>> because it will solve itself due to market forces. Right now there
>> is no IPv6-only content that anyone cares about. When that changes,
>> users will start demanding that their provider give them access to
>> it, or vote with their feet.
>
> Whenever people talk about the Internet as if it were just about
> "access to content", I have to wonder.    The Internet has always
> been more about conversation than content.

The overwhelming majority of Internet users are consumers of content. 
Some of that content is stuff like Skype, instant messaging, etc.

The overwhelming majority of businesses that make the Internet work are 
the content providers, and the ISPs that enable the consumers of that 
content to reach it.

Failure to recognize these 2 critical facts leads to producing standards 
documents that have no relevance in the real world.

>> To summarize my main point once again, there is nothing for the
>> IETF to do here, the problem will take care of itself.
>
> Quite the contrary.  We still don't have a good transition mechanism
> that HOMENET could specify.

And as I pointed out in the bits of my message that you snipped, we 
don't need one.

Doug

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

From: Joel Jaeggli <[email-masked]>
Date: Sat, 2 Jul 2011 11:53:51 -0700
To: Cullen Jennings <[email-masked]>
Cc: [email-masked]
Subject: Re: [fun] Routing ?

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

That said...

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

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

joel

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

> 
> I'm sure this is a spectacularly clueless question but, .... could someone say a bit more about why we need a routing protocol. I get that there is a need for small number of subnets, but it seems like most the requirements I have seen could be deal with using a single router that could route between all the subnets. As I said, clueless questions but can someone fill me in a bit on the use cases for a routing protocol? Or why a new routing protocol might be needed. Thanks. 
> 
> 
> 
> On Jun 29, 2011, at 2:35 AM, Jari Arkko wrote:
> 
>> I wanted to provide an update of the situation with this working group proposal.
>> 
>> HOMENET is a new working group proposal, a variation of the HOMEGATE/HOMENET theme that we discussed last year, but this time looking at it from a different angle. The old effort was mostly focused about what home gateways should do: forwarding, transport, and DNS proxying issues. The new effort is about home networks themselves, in particular what kind of network architecture and configuration is necessary to support IPv6-based home networks. We view IPv4-based home networks as "done" at this time (or perhaps as "cannot be changed anyway").
>> 
>> I have been discussing this effort in the background for the last couple of month with Mark Townsley and others, and more publicly since early June. The proposal has been brought to the IESG, IAB and some directorates for discussion, and we've been going back and forth whether this is ready to become a working group or needs to be run as a BOF in Quebec City. The current plan is that the working group proposal goes to IETF-wide review this week, and if the feedback from the community, IAB, and the IESG is positive, we will create the working group just in time for the IETF. Otherwise, the slot reserved in the agenda for the meeting will be used to run the proposal as a BOF.
>> 
>> In any case, I would like to solicit discussion on this topic, and perhaps some early drafts as well. Please comment on the charter at least.
>> 
>> Note that the new proposal was called FUN at the time that we created the list. It has now been renamed back to HOMENET to be more descriptive. The list will be renamed soon as well (current subscribers will stay).
>> 
>> This is the most recent version of the charter we should discuss:
>> 
>> Home Networks (homenet)
>> -----------------------------------
>> 
>> 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
>> 
>> _______________________________________________
>> fun mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/fun
> 
> _______________________________________________
> fun mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/fun
> 

From: Cullen Jennings <[email-masked]>
Date: Sat, 2 Jul 2011 06:31:51 -0600
To: Jari Arkko <[email-masked]>
Cc: [email-masked]
Subject: Re: [fun] Routing ?

Thanks - that makes sense. 

On Jul 2, 2011, at 2:01 AM, Jari Arkko wrote:

> Cullen,
> 
> Good question.
> 
> The charter does say that new routing protocols are NOT in scope, however. There may be a need to run a routing protocol, but if so, it would be an existing one.
> 
> But back to your question. Do we need a routing protocol, or can a single router be at the center and deal with all? I think the single router model is a good one even when there are multiple subnets. That being said, when you plug in. say,  the first sensor-network-to-WLAN router that can't do bridging you're in trouble. I personally think we should build for the case where there are multiple routers, while hoping that there is just one and that the number of subnets is either 1 or at least a very small number.
> 
> Jari
> 
> Cullen Jennings kirjoitti:
>> I'm sure this is a spectacularly clueless question but, .... could someone say a bit more about why we need a routing protocol. I get that there is a need for small number of subnets, but it seems like most the requirements I have seen could be deal with using a single router that could route between all the subnets. As I said, clueless questions but can someone fill me in a bit on the use cases for a routing protocol? Or why a new routing protocol might be needed. Thanks. 
>> 
>> 
>> On Jun 29, 2011, at 2:35 AM, Jari Arkko wrote:
>> 
>>  
>>> I wanted to provide an update of the situation with this working group proposal.
>>> 
>>> HOMENET is a new working group proposal, a variation of the HOMEGATE/HOMENET theme that we discussed last year, but this time looking at it from a different angle. The old effort was mostly focused about what home gateways should do: forwarding, transport, and DNS proxying issues. The new effort is about home networks themselves, in particular what kind of network architecture and configuration is necessary to support IPv6-based home networks. We view IPv4-based home networks as "done" at this time (or perhaps as "cannot be changed anyway").
>>> 
>>> I have been discussing this effort in the background for the last couple of month with Mark Townsley and others, and more publicly since early June. The proposal has been brought to the IESG, IAB and some directorates for discussion, and we've been going back and forth whether this is ready to become a working group or needs to be run as a BOF in Quebec City. The current plan is that the working group proposal goes to IETF-wide review this week, and if the feedback from the community, IAB, and the IESG is positive, we will create the working group just in time for the IETF. Otherwise, the slot reserved in the agenda for the meeting will be used to run the proposal as a BOF.
>>> 
>>> In any case, I would like to solicit discussion on this topic, and perhaps some early drafts as well. Please comment on the charter at least.
>>> 
>>> Note that the new proposal was called FUN at the time that we created the list. It has now been renamed back to HOMENET to be more descriptive. The list will be renamed soon as well (current subscribers will stay).
>>> 
>>> This is the most recent version of the charter we should discuss:
>>> 
>>> Home Networks (homenet)
>>> -----------------------------------
>>> 
>>> 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
>>> 
>>> _______________________________________________
>>> fun mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/fun
>>>    
>> 
>> _______________________________________________
>> fun mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/fun
>> 
>>  
> 

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

Content-class: urn:content-classes:message
Date: Sat, 2 Jul 2011 06:18:12 -0500
From: "JP Vasseur (jvasseur)" <[email-masked]>
To: <[email-masked]>, "Cullen Jennings (fluffy)" <[email-masked]>
Cc: [email-masked]
Subject: Re: [fun] Routing ?

Date: Sat, 2 Jul 2011 11:19:58 +0200 (CEST)
From: Mikael Abrahamsson <[email-masked]>
To: [email-masked]
Organization: People's Front Against WWW
Subject: Re: [fun] Routing ?

On Sat, 2 Jul 2011, Jari Arkko wrote:

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

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

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

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

-- 
Mikael Abrahamsson    email: [email-masked]

Date: Sat, 02 Jul 2011 10:01:41 +0200
From: Jari Arkko <[email-masked]>
To: Cullen Jennings <[email-masked]>
Cc: [email-masked]
Subject: Re: [fun] Routing ?

Cullen,

Good question.

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

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

Jari

Cullen Jennings kirjoitti:
> I'm sure this is a spectacularly clueless question but, .... could someone say a bit more about why we need a routing protocol. I get that there is a need for small number of subnets, but it seems like most the requirements I have seen could be deal with using a single router that could route between all the subnets. As I said, clueless questions but can someone fill me in a bit on the use cases for a routing protocol? Or why a new routing protocol might be needed. Thanks. 
>
>
>
> On Jun 29, 2011, at 2:35 AM, Jari Arkko wrote:
>
>   
>> I wanted to provide an update of the situation with this working group proposal.
>>
>> HOMENET is a new working group proposal, a variation of the HOMEGATE/HOMENET theme that we discussed last year, but this time looking at it from a different angle. The old effort was mostly focused about what home gateways should do: forwarding, transport, and DNS proxying issues. The new effort is about home networks themselves, in particular what kind of network architecture and configuration is necessary to support IPv6-based home networks. We view IPv4-based home networks as "done" at this time (or perhaps as "cannot be changed anyway").
>>
>> I have been discussing this effort in the background for the last couple of month with Mark Townsley and others, and more publicly since early June. The proposal has been brought to the IESG, IAB and some directorates for discussion, and we've been going back and forth whether this is ready to become a working group or needs to be run as a BOF in Quebec City. The current plan is that the working group proposal goes to IETF-wide review this week, and if the feedback from the community, IAB, and the IESG is positive, we will create the working group just in time for the IETF. Otherwise, the slot reserved in the agenda for the meeting will be used to run the proposal as a BOF.
>>
>> In any case, I would like to solicit discussion on this topic, and perhaps some early drafts as well. Please comment on the charter at least.
>>
>> Note that the new proposal was called FUN at the time that we created the list. It has now been renamed back to HOMENET to be more descriptive. The list will be renamed soon as well (current subscribers will stay).
>>
>> This is the most recent version of the charter we should discuss:
>>
>> Home Networks (homenet)
>> -----------------------------------
>>
>> 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
>>
>> _______________________________________________
>> fun mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/fun
>>     
>
> _______________________________________________
> fun mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/fun
>
>   

From: Fred Baker <[email-masked]>
Date: Fri, 1 Jul 2011 23:20:35 -0700
To: [email-masked]
Subject: [fun] Fwd: New Version Notification for draft-baker-fun-multi-router-00.txt

FYI

Begin forwarded message:

> From: [email-masked]
> Date: July 1, 2011 11:19:30 PM PDT
> To: [email-masked]
> Cc: [email-masked]
> Subject: New Version Notification for draft-baker-fun-multi-router-00.txt
> 
> A new version of I-D, draft-baker-fun-multi-router-00.txt has been successfully submitted by Fred Baker and posted to the IETF repository.
> 
> Filename:	 draft-baker-fun-multi-router
> Revision:	 00
> Title:		 Exploring the multi-router SOHO network
> Creation date:	 2011-07-01
> WG ID:		 Individual Submission
> Number of pages: 12
> 
> Abstract:
>   This note explores the ramifications of a multi-router or multihomed
>   small network, such as a residential or SOHO network.
> 
> Requirements
> 
> 
> 
> The IETF Secretariat

From: Fred Baker <[email-masked]>
Date: Fri, 1 Jul 2011 23:20:07 -0700
To: [email-masked]
Subject: [fun] Fwd: New Version Notification for draft-baker-fun-routing-class-00.txt

FYI

Begin forwarded message:

> From: [email-masked]
> Date: July 1, 2011 11:17:25 PM PDT
> To: [email-masked]
> Cc: [email-masked]
> Subject: New Version Notification for draft-baker-fun-routing-class-00.txt
> 
> A new version of I-D, draft-baker-fun-routing-class-00.txt has been successfully submitted by Fred Baker and posted to the IETF repository.
> 
> Filename:	 draft-baker-fun-routing-class
> Revision:	 00
> Title:		 Routing a Traffic Class
> Creation date:	 2011-07-01
> WG ID:		 Individual Submission
> Number of pages: 14
> 
> Abstract:
>   This note addresses the concept of routing a traffic class.  This has
>   many possible implementations, IGP and BGP, and link state as well as
>   distance vector.  The fundamental impetus is the question raised in
>   RFC 3704 and shim6 of exit routing, the question raised by Mike
>   O&#39;Dell of source/destination routing, and the &quot;fish&quot; problem, raised
>   in many networks, in which distinct traffic classes that could
>   conceivably use the same route predictably use different routes.
>   Instead of handling these as &quot;destination routing with a twist&quot;, the
>   paper looks at the matter systemically.
> 
> Requirements
> 
> 
> 
> The IETF Secretariat

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

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

On Jun 29, 2011, at 2:35 AM, Jari Arkko wrote:

> I wanted to provide an update of the situation with this working group proposal.
> 
> HOMENET is a new working group proposal, a variation of the HOMEGATE/HOMENET theme that we discussed last year, but this time looking at it from a different angle. The old effort was mostly focused about what home gateways should do: forwarding, transport, and DNS proxying issues. The new effort is about home networks themselves, in particular what kind of network architecture and configuration is necessary to support IPv6-based home networks. We view IPv4-based home networks as "done" at this time (or perhaps as "cannot be changed anyway").
> 
> I have been discussing this effort in the background for the last couple of month with Mark Townsley and others, and more publicly since early June. The proposal has been brought to the IESG, IAB and some directorates for discussion, and we've been going back and forth whether this is ready to become a working group or needs to be run as a BOF in Quebec City. The current plan is that the working group proposal goes to IETF-wide review this week, and if the feedback from the community, IAB, and the IESG is positive, we will create the working group just in time for the IETF. Otherwise, the slot reserved in the agenda for the meeting will be used to run the proposal as a BOF.
> 
> In any case, I would like to solicit discussion on this topic, and perhaps some early drafts as well. Please comment on the charter at least.
> 
> Note that the new proposal was called FUN at the time that we created the list. It has now been renamed back to HOMENET to be more descriptive. The list will be renamed soon as well (current subscribers will stay).
> 
> This is the most recent version of the charter we should discuss:
> 
> Home Networks (homenet)
> -----------------------------------
> 
> 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
> 
> _______________________________________________
> fun mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/fun

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

Hi James,

> I suspect it wouldn't take much to adapt 6RD to these ends.
> Remember, 6RD tunnels do*not*  need to be terminated by the provider
> network.  They can be terminated by a third-party with minimal human
> interface burden.  Perhaps I should find the time to write a draft on
> the topic.

Finding a time to write a draft is a great idea. However I think even 
better idea would be to find and wiki the list of actual providers 
anyone could terminate his 6RD to.

R.

From: james woodyatt <[email-masked]>
Date: Fri, 01 Jul 2011 16:17:18 -0700
To: [email-masked]
Subject: Re: [fun] [homegate] HOMENET working group proposal

[distribution narrowed to FUN list]

On Jul 1, 2011, at 13:43 , Noel Chiappa wrote:
> 
> <Innocent face=on>
> You mean, like with 6to4?
> <Innocent face=off>

Actually, I suspect that operator hostility to 6to4 is high enough that devising some stealthier means of making their dumb IPv4-only networks serve our higher purposes will be necessary.  I joke that we should use a stylized audio feedback that reminds the listener of an old acoustic modem when signaling the establishment of such a tunnel, because that's a pretty good metaphor for what we'd be doing.

I suspect it wouldn't take much to adapt 6RD to these ends.  Remember, 6RD tunnels do *not* need to be terminated by the provider network.  They can be terminated by a third-party with minimal human interface burden.  Perhaps I should find the time to write a draft on the topic.

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

From: Christopher Palmer <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Fri, 1 Jul 2011 22:52:09 +0000
Accept-Language: en-US
Subject: [fun] Feedback - HomeNet Charter

--_000_0AB09EDBCD1C484EBE45978D62F3513C3CE7D5DBTK5EX14MBXW601w_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hey Folks,

I've been trying to keep track of all the feedback concerning the HomeNet Charter. Sorry for bringing up points that may have been discussed before, or are in general noobish.

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

We are absolutely aligned to this objective. IPv6 provides an opportunity to avoid the limiting topology of current IPv4 deployments and this should a priority for everyone in the technology community.

I have points of concern. "Managing routing" is a very broad category of things and I'm not clear about what the vision is there.

The focus on multiple subnet solutions doesn't seemed align to current operational reality. While I understand the desire to be forward looking, this seems "very" forward looking to a point. I'd be interested in data that reflects the contrary.

Windows and Apple currently use different mechanisms for service discovery. Is unification a goal? WSD is managed by OASIS, which isn't mentioned for liasoning. Would we imagine the multicast DNS draft moving over to this WG? I'm just confused on what is happening and what is intended to happen. While the charter says routing changes will be handled by the routing area working group, the charter is not that specific on DNS changes.

I feel like the vision and defining principles could be spelled out more. We want IPv6 home networks to be routable. OK.  What else do we want? Why are we doing this?

"The purpose of this working group is to focus on this evolution...." To what end?

The requirements list reads "a solution will cover these technology areas" - I'd be interested in some definition of what promises those technology areas are meant to fulfill, the shape of the solution, not just its composition.

Best,
Chris
IPv6 @ Windows

--_000_0AB09EDBCD1C484EBE45978D62F3513C3CE7D5DBTK5EX14MBXW601w_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">Hey Folks,<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">I&#8217;ve been trying to keep track of all the feedback concerning the HomeNet Charter. Sorry for bringing up points that may have been discussed before, or are in general noobish.<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">&#8220;End-to-end communication is both an opportunity and a concern as it<o:p></o:p></p>
<p class="MsoNormal">enables new applications but also exposes nodes in the internal<o:p></o:p></p>
<p class="MsoNormal">networks to receipt of unwanted traffic from the Internet. Firewalls<o:p></o:p></p>
<p class="MsoNormal">that restrict incoming connections may be used to prevent exposure,<o:p></o:p></p>
<p class="MsoNormal">however, this reduces the efficacy of end-to-end connectivity that<o:p></o:p></p>
<p class="MsoNormal">IPv6 has the potential to restore.&#8221;<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">We are absolutely aligned to this objective. IPv6 provides an opportunity to avoid the limiting topology of current IPv4 deployments and this should a priority for everyone in the technology community.<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">I have points of concern. &#8220;Managing routing&#8221; is a very broad category of things and I&#8217;m not clear about what the vision is there.
<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">The focus on multiple subnet solutions doesn&#8217;t seemed align to current operational reality. While I understand the desire to be forward looking, this seems &#8220;very&#8221; forward looking to a point. I&#8217;d be interested in data that reflects the contrary.<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Windows and Apple currently use different mechanisms for service discovery. Is unification a goal? WSD is managed by OASIS, which isn&#8217;t mentioned for liasoning. Would we imagine the multicast DNS draft moving over to this WG? I&#8217;m just confused
 on what is happening and what is intended to happen. While the charter says routing changes will be handled by the routing area working group, the charter is not that specific on DNS changes.<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">I feel like the vision and defining principles could be spelled out more. We want IPv6 home networks to be routable. OK. &nbsp;What else do we want? Why are we doing this?
<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">&#8220;The purpose of this working group is to focus on this evolution&#8230;.&#8221; To what end?<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">The requirements list reads &#8220;a solution will cover these technology areas&#8221; &#8211; I&#8217;d be interested in some definition of what promises those technology areas are meant to fulfill, the shape of the solution, not just its composition.<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Best,<o:p></o:p></p>
<p class="MsoNormal">Chris<o:p></o:p></p>
<p class="MsoNormal">IPv6 @ Windows<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
</body>
</html>

--_000_0AB09EDBCD1C484EBE45978D62F3513C3CE7D5DBTK5EX14MBXW601w_--

Date: Sat, 02 Jul 2011 00:14:52 +0200
From: Robert Raszuk <[email-masked]>
To: Jari Arkko <[email-masked]>
Cc: [email-masked]
Subject: Re: [fun] status of the homenet effort
Reply-To: [email-masked]

Hi Jari,

> As Mark noted, some aspects of diagnostics and troubleshooting are
> inherent in the notion of automatic configuration. Prefix delegation,
> routing, etc. has to figure out if there is connectivity and what to do
> if there isn't. But its mostly automatic, not built for human network
> managers to play with.

Well honestly while I agree that automation is great for vast majority 
of home networks, unfortunately for someone like me it is just scary - 
maybe too scary. If I buy or rent a car I always pick manual ... (maybe 
wrong comparison maybe not ... but it is just a matter of awareness of 
one's skills of control).

> I think multihoming solutions should be out of scope.

Maybe I was not sufficiently precise. I am not asking to roll-out new 
models of PIC or active/active load balancing for home networks.

I am just trying to see a room for a spec which would define what should 
be the CPE behaviour when someone connects two DSL/Cable/Mixed lines to 
it. I hope we would not prohibit it ... and if not the behaviour needs 
to be either defined here or referenced as Mark mentioned earlier to 
other documents which solve this already.

Many thx,
R.

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

Doug,

> This is an area that we very clearly do not need to get involved in
> because it will solve itself due to market forces.

Maybe it will, but why not make it easier for early adopters ? 
Especially for those who would like to start offering some v6 content 
over their v4 ISPs today.

It seems that this is equally useful as AMT (Automatic IP Multicast 
Without Explicit Tunnels) as described in the below IETF WG doc:
draft-ietf-mboned-auto-multicast-10

R.

Date: Fri, 01 Jul 2011 23:48:12 +0200
From: Jari Arkko <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [fun] status of the homenet effort

Robert,

Thank you for very interesting questions.

As Mark noted, some aspects of diagnostics and troubleshooting are 
inherent in the notion of automatic configuration. Prefix delegation, 
routing, etc. has to figure out if there is connectivity and what to do 
if there isn't. But its mostly automatic, not built for human network 
managers to play with.

Maybe the answers to your question are clearer once we have completed 
the architecture work. Maybe there are some additional diagnostics 
needs, but at this point I'll admit that I don't see them.

Whereas...

>> 2. How about multihoming with seamless switchover ?
>>     
>
> This particular elephant has been in and out of various versions of the charter. I'll plead the 5th on this one and ask Jari to describe where we are on this, in particular in relation to mif, shim6, lisp, rrg, v6ops, or any of the other areas that are touching on this. 
>
> Personally, I think it would be naive to not include the various possibilities of multihomed connectivity, at the vary least in describing the architecture for which we will work within. I don't think homenet is the place to solve the general issue of "seamless multihoming" at the protocol level, but perhaps we would point to what works well in a home setting... we might even agree to one way to do it if we are really, really, lucky. 
>   

I think multihoming solutions should be out of scope. Not because they 
are uninteresting, they're not -- they are very important. And I know 
there are specific requirements for it in some home network cases. But 
it is a very complex and challenging topic by itself, and one where we 
have multiple IETF workings groups already. I agree with Mark though 
that we may point to some solutions and think about this during the 
architecture work, but even there I'd be a bit careful not to taken on 
too ambitious tasks.

Jari

From: Keith Moore <[email-masked]>
Date: Fri, 1 Jul 2011 17:17:51 -0400
To: Doug Barton <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [fun] [homegate] HOMENET working group proposal

On Jul 1, 2011, at 4:13 PM, Doug Barton wrote:

> On 07/01/2011 13:03, Kenneth Voort wrote:
>> I would also add that future IPv6 capable devices should allow end users to reach the IPv6 Internet
>> from an IPv4-only provider through some means, perhaps tunneling, with no or minimal administrator
>> intervention. I can see many providers remaining IPv4-only long into the future.
> 
> This is an area that we very clearly do not need to get involved in because it will solve itself due to market forces. Right now there is no IPv6-only content that anyone cares about. When that changes, users will start demanding that their provider give them access to it, or vote with their feet.

Whenever people talk about the Internet as if it were just about "access to content", I have to wonder.    The Internet has always been more about conversation than content.  

> To summarize my main point once again, there is nothing for the IETF to do here, the problem will take care of itself.

Quite the contrary.  We still don't have a good transition mechanism that HOMENET could specify.   6to4 has problems as we're now painfully aware; configured tunnels and Teredo have different problems.  There's still room for work in this space if better solutions can be identified.  Though it doesn't seem appropriate to ask the HOMENET WG to develop them.

Keith

From: Keith Moore <[email-masked]>
Date: Fri, 1 Jul 2011 17:14:25 -0400
To: Kenneth Voort <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [fun] [homegate] HOMENET working group proposal

On Jul 1, 2011, at 4:03 PM, Kenneth Voort wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I would also add that future IPv6 capable devices should allow end users to reach the IPv6 Internet
> from an IPv4-only provider through some means, perhaps tunneling, with no or minimal administrator
> intervention. I can see many providers remaining IPv4-only long into the future.

+1

To: [email-masked], [email-masked]
Date: Fri,  1 Jul 2011 16:43:01 -0400 (EDT)
From: [email-masked] (Noel Chiappa)
Cc: [email-masked]
Subject: Re: [fun] [homegate] HOMENET working group proposal

    > From: Kenneth Voort <[email-masked]>

    > future IPv6 capable devices should allow end users to reach the IPv6
    > Internet from an IPv4-only provider through some means, perhaps
    > tunneling, with no or minimal administrator intervention.

<Innocent face=on>
You mean, like with 6to4?
<Innocent face=off>

(Sorry, couldn't resist! :-)

	Noel

Date: Fri, 01 Jul 2011 13:13:41 -0700
From: Doug Barton <[email-masked]>
Organization: http://SupersetSolutions.com/
To: Kenneth Voort <[email-masked]>
OpenPGP: id1ABC84
Cc: [email-masked], [email-masked]
Subject: Re: [fun] [homegate] HOMENET working group proposal

On 07/01/2011 13:03, Kenneth Voort wrote:
> I would also add that future IPv6 capable devices should allow end users to reach the IPv6 Internet
> from an IPv4-only provider through some means, perhaps tunneling, with no or minimal administrator
> intervention. I can see many providers remaining IPv4-only long into the future.

This is an area that we very clearly do not need to get involved in 
because it will solve itself due to market forces. Right now there is no 
IPv6-only content that anyone cares about. When that changes, users will 
start demanding that their provider give them access to it, or vote with 
their feet.

That said, I don't see IPv6-only content happening any time in the next 
5 years, at least. Content providers do not want to cut themselves off 
from 99.9% of their potential user base.

What's going to encourage IPv6 adoption on the content side are things 
like smart phones that use it natively (which is already happening). 
Content providers will see (and many are already seeing) that it is in 
their own best interest to get their content up on IPv6.

The ISP side will be dragged kicking and screaming into the IPv6 world 
in the next couple of years as the IPv4 addresses really do dry up, and 
the cost of obtaining more on the gray market begins to exceed the cost 
of deploying IPv6. And of course, some just won't make the transition, 
and will ultimately fail. C'est la vie.

To summarize my main point once again, there is nothing for the IETF to 
do here, the problem will take care of itself.

Doug

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

Date: Fri, 01 Jul 2011 16:03:55 -0400
From: Kenneth Voort <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [fun] [homegate] HOMENET working group proposal

I would also add that future IPv6 capable devices should allow end users to reach the IPv6 Internet
from an IPv4-only provider through some means, perhaps tunneling, with no or minimal administrator
intervention. I can see many providers remaining IPv4-only long into the future.

On 11-06-30 5: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

- -- 
Kenneth Voort - kenneth {at} voort <SPAMGUARD> {dot} ca
FDF1 6265 EBAB C05C FD06 1AED 158E 14D6 37CD E87F | pgp encrypted email preferred

From: Keith Moore <[email-masked]>
Date: Fri, 1 Jul 2011 14:30:58 -0400
To: Stephen [kiwin] PALM <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, IETF Discussion <[email-masked]>
Subject: Re: [fun] [homegate] HOMENET working group proposal

Anytime we develop standards, the standards apply to future products.  There's no point in defining standards for applications and devices that are already deployed.

Sure, it's nice to have backward compatibility.  But I don't think anyone is likely to propose standards for HOMENET that will significantly break compatibility with existing products.  It's not as if the set of applications and devices that one uses in a home network is disjoint from the set of applications and devices used in other networks.   And it's reasonable to expect that users of existing applications and devices might need to do some special-case configuration to get those applications and devices to continue to work.  

Just to pick one example, if a legacy device is v4-only, and the only access available is NATted v4 or native v6, there might be a need to configure the device to be externally accessible using a v6 address.  The home network might support v4 internally but there might not be v4 service available outside that enclave.

Backward compatibility = good.  Insisting that home networks always use the same kludges that are used now = bad.

Maybe the right answer is that the HOMENET group should consider what means are needed to provide some measure of compatibility with legacy devices and applications, that might continue to be used with networks meeting the new standards.  The working group seems like it's in a much better position than the IETF list to propose reasonable compromises on these issues.

Keith

On Jun 30, 2011, at 12:17 PM, Stephen [kiwin] PALM wrote:

> 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]
> 
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

From: james woodyatt <[email-masked]>
Date: Fri, 01 Jul 2011 09:37:46 -0700
To: Martin Focazio <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [fun] [homegate]  HOMENET working group proposal

On Jun 30, 2011, at 6:34 PM, Martin Focazio wrote:
> 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 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.
> 
> 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.

Telecommunications services are still ostensibly a regulated utility in the USA.

If the people living in those areas neither want to move, nor demand their utility commissions to hold service providers accountable for the proper operation of the monopoly franchise they receive from the government, then those people are making their choice.  Choosing an alternative is possible.  It entails either individual action to relocate or collective action to reform the telecommunications services.  Inaction, of course, is also an alternative.  People choose one or the other.

As I said, Alice can break Bob's applications by choosing her service provider.  And vice versa.

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

From: Mark Townsley <[email-masked]>
Date: Fri, 1 Jul 2011 17:47:39 +0200
To: "Weil, Jason" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "JP Vasseur \(jvasseur\)" <[email-masked]>
Subject: Re: [fun] [homegate]  status of the homenet effort

On Jul 1, 2011, at 5:06 PM, Weil, Jason wrote:

> Agreed. My thought was Homenet builds consensus on what work is needed and possibly sets the requirements. The development work should occur in whatever group is responsible for that technology.

I think homenet could set defaults (not far removed from requirements, and something that is imperative in a home network and less so in others). Also, depending on the protocol involved, there may or may not be a WG setup to do the work - for example, DHCP's modus operandi is that simple DHCP options are defined not in the DHC WG itself, but in the "parent technology" WG with review from DHC. 

In any case, I think this is why Jari included a  review stage of the work to be done after we get through the architecture/framework... We'll know better then what work can be knocked out under a homenet banner, and what needs to be forked elsewhere. 

- Mark

> 
> Jason
> 
> -----Original Message-----
> From: JP Vasseur (jvasseur) [mailto:[email-masked]]
> Sent: Friday, July 01, 2011 11:02 AM
> To: Ralph Droms (rdroms); Weil, Jason
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [homegate] [fun] status of the homenet effort
> 
> Agreeing with Ralph.
> 
> JP Vasseur
> Cisco Fellow
> 
> Sent from Blackberry
> 
> ----- Original Message -----
> From: Ralph Droms (rdroms)
> Sent: Friday, July 01, 2011 09:37 AM
> To: Weil, Jason <[email-masked]>
> Cc: Mark Townsley <[email-masked]>; JP Vasseur (jvasseur); [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
> Subject: Re: [homegate] [fun] status of the homenet effort
> 
> 
> On Jul 1, 2011, at 9:32 AM 7/1/11, Weil, Jason wrote:
> 
>> 
>> 
>> On 7/1/11 4:06 AM, "Mark Townsley" <[email-masked]> wrote:
>> 
>>> 
>>> On Jul 1, 2011, at 7:27 AM, JP Vasseur (jvasseur) wrote:
>>> 
>>>> 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?
>>> 
>>> At least a section within a home architecture document.
>>> 
>>>> * A recommendation for a specific routing protocol ?
>> 
>> [JW] I see a guidelines/analysis for link-state vs. distance-vector
>> routing protocols in a multi-segment home network as being useful.
> 
> In my opinion, operation without active admin intervention is more important than the particular technology.
> 
>>>> * A framework before the specification of a new routing protocol ?
>> 
>> [JW] A framework or justification statement for a new lightweight routing
>> protocol would be useful as well. A source/dest aware protocol has been
>> proposed as a possible solution for the multi-homed home network for
>> example.
> 
>>> The charter says:
>>> 
>>> "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."
> 
> Source/dest aware protocol sounds more like a research project.  Developing requirements might be in scope for homenet.
> 
> - Ralph
> 
>>> 
>>> - Mark
>>> 
>>> 
>>>> 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,
>>>>> 
>>>>> 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 �residential home� networks. For
>>>>>>> example, an obvious trend in home networking is the proliferation of
>>>>>>> networking technology in an increasingly broad range and number of
>>>>>>> devices. This evolution in scale and diversity sets some requirements
>>>>>>> on IETF protocols. Some of the relevant trends include:
>>>>>>> 
>>>>>>> o Multiple segments: While less complex L3-toplogies involving as few
>>>>>>> subnets as possible are preferred in home networks for a variety of
>>>>>>> reasons including simpler management and service discovery, the
>>>>>>> introduction of more than one subnet into a home network is enough
>>>>>>> to add complexity that needs to be addressed, and multiple
>>>>>>> dedicated segments are necessary for some cases. For instance, a
>>>>>>> common feature in modern home routers in the ability to support
>>>>>>> both guest and private network segments. Also, link layer
>>>>>>> networking technology is poised to become more heterogeneous, as
>>>>>>> networks begin to employ both traditional Ethernet technology and
>>>>>>> link layers designed for low-powered sensor networks. Finally,
>>>>>>> similar needs for segmentation may occur in other cases, such as
>>>>>>> separating building control or corporate extensions from the
>>>>>>> Internet access network. Different segments may be associated with
>>>>>>> subnets that have different routing and security policies.
>>>>>>> 
>>>>>>> o Service providers are deploying IPv6, and support for IPv6 is
>>>>>>> increasingly available in home gateway devices. While IPv6 resembles
>>>>>>> IPv4 in many ways, it changes address allocation principles and
>>>>>>> allows
>>>>>>> direct IP addressability and routing to devices in the home from the
>>>>>>> Internet. This is a promising area in IPv6 that has proved
>>>>>>> challenging
>>>>>>> in IPv4 with the proliferation of NAT.
>>>>>>> 
>>>>>>> o End-to-end communication is both an opportunity and a concern as it
>>>>>>> enables new applications but also exposes nodes in the internal
>>>>>>> networks to receipt of unwanted traffic from the Internet. Firewalls
>>>>>>> that restrict incoming connections may be used to prevent exposure,
>>>>>>> however, this reduces the efficacy of end-to-end connectivity that
>>>>>>> IPv6 has the potential to restore.
>>>>>>> 
>>>>>>> Home networks need to provide the tools to handle these situations in
>>>>>>> a manner accessible to all users of home networks. Manual
>>>>>>> configuration is rarely, if at all, possible. The purpose of this
>>>>>>> working group is to focus on this evolution, in particular as it
>>>>>>> addresses the introduction of IPv6, by developing an architecture
>>>>>>> addressing this full scope of requirements:
>>>>>>> 
>>>>>>> o prefix configuration for routers
>>>>>>> o managing routing
>>>>>>> o name resolution
>>>>>>> o service discovery
>>>>>>> o network security
>>>>>>> 
>>>>>>> The task of the group is to produce an architecture document that
>>>>>>> outlines how to construct home networks involving multiple routers
>>>>>>> and
>>>>>>> subnets. This document is expected to apply the IPv6 addressing
>>>>>>> architecture, prefix delegation, global and ULA addresses, source
>>>>>>> address selection rules and other existing components of the IPv6
>>>>>>> architecture. The architecture document should drive what protocols
>>>>>>> changes, if any, are necessary. Specific protocol work described
>>>>>>> below
>>>>>>> is expected to be within the scope of the working group one the
>>>>>>> architecture work is complete. However, the group is required to
>>>>>>> review its charter and milestones with the IESG and IETF community
>>>>>>> before submitting documents that make protocol changes. It is
>>>>>>> expected
>>>>>>> that the group has to discuss some of the below solutions, however,
>>>>>>> in
>>>>>>> order to complete the architecture work.
>>>>>>> 
>>>>>>> The group will apply existing protocols to handle the five
>>>>>>> requirements above. For prefix configuration, existing protocols are
>>>>>>> likely sufficient, and at worst may need some small enhancements,
>>>>>>> such
>>>>>>> as new options. For automatic routing, it is expected that existing
>>>>>>> routing protocols can be used as is, however, a new mechanism may be
>>>>>>> needed in order to turn a selected protocol on by default. For name
>>>>>>> resolution and service discovery, extensions to existing
>>>>>>> multicast-based name resolution protocols are needed to enable them
>>>>>>> to
>>>>>>> work across subnets.
>>>>>>> 
>>>>>>> For network security, the group shall document the concept of
>>>>>>> "advanced security" as a further development of "simple security"
>>>>>>> from
>>>>>>> RFC 6092. The main goal of this work is to enable a security policy
>>>>>>> that adapts to IPv6 threats as they emerge, taking into account not
>>>>>>> only traffic from the Internet at large, but within and leaving the
>>>>>>> home network itself.
>>>>>>> 
>>>>>>> It is expected that the working group will define a set of protocol
>>>>>>> specifications to accomplish the five requirements from
>>>>>>> above. However, it is not in the scope of the working group to define
>>>>>>> entirely new routing protocols or address allocation protocols. As
>>>>>>> noted, additional options or other small extensions may be necessary
>>>>>>> to use the existing protocols in these new configuration tasks. The
>>>>>>> working group shall also not make any changes to IPv6 protocols or
>>>>>>> addressing architecture. Prefix configuration, routing, and security
>>>>>>> related work shall not cause any changes that are not backwards
>>>>>>> compatible to existing IPv6 hosts. There may be host visible changes
>>>>>>> in the work on naming and discovery protocols, however. In its
>>>>>>> design,
>>>>>>> the working group shall also consider security aspects and the impact
>>>>>>> on manageability. The main focus of the working group is home
>>>>>>> networks, but the group's results may also find applications in other
>>>>>>> small networks.
>>>>>>> 
>>>>>>> The working group will liaise with the relevant IETF working
>>>>>>> groups. In particular, the group should work closely with the V6OPS
>>>>>>> working group, review any use or extension of DHCP with the DHC
>>>>>>> working group, and work with additional DNS requirements with the
>>>>>>> DNSEXT and DNSOP working groups. If it turns out that additional
>>>>>>> options are needed for a routing protocol, they will be developed in
>>>>>>> the appropriate Routing Area working group, with the HOMENET working
>>>>>>> group providing the architecture and requirements for such
>>>>>>> enhancements. The working group will also liase with external
>>>>>>> standards bodies where it is expected that there are normative
>>>>>>> dependencies between the specifications of the two bodies.
>>>>>>> It is expected that in the architecture definition stage liaising
>>>>>>> with the Broadband Forum, DLNA, and UPnP Forum is necessary.
>>>>>>> 
>>>>>>> Milestones:
>>>>>>> 
>>>>>>> Jul 2011 Formation of the working group
>>>>>>> Sep 2011 First WG draft on the architecture
>>>>>>> Dec 2011 Submission of the architecture draft to the IESG as
>>>>>>> Informational RFC
>>>>>>> Dec 2011 Charter re-evaluation based on the architecture work
>>>>>>> Dec 2011 First WG draft on prefix configuration
>>>>>>> Dec 2011 First WG draft on routing
>>>>>>> Jan 2012 First WG draft on name resolution
>>>>>>> Feb 2012 First WG draft on service discovery
>>>>>>> Feb 2012 First WG draft on perimeter security
>>>>>>> Feb 2012 Start of routing related work in the relevant routing area
>>>>>>> working group, if needed
>>>>>>> Mar 2012 Submission of the prefix configuration draft to the IESG as
>>>>>>> Standards Track RFC
>>>>>>> Apr 2012 Submission of the routing draft to the IESG as Informational
>>>>>>> RFC
>>>>>>> Sep 2012 Submission of the name resolution draft to the IESG as
>>>>>>> Standards Track RFC
>>>>>>> Nov 2012 Submission of the service discovery draft to the IESG as
>>>>>>> Standards Track RFC
>>>>>>> Dec 2012 Submission of the perimeter security draft to the IESG as
>>>>>>> Informational RFC
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> fun mailing list
>>>>>>> [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
>>>>> 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
>>> 
>> 
>> 
>> 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.
>> _______________________________________________
>> homegate mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/homegate
> 

From: "Weil, Jason" <[email-masked]>
To: "JP Vasseur (jvasseur)" <[email-masked]>, "Ralph Droms (rdroms)" <[email-masked]>
Date: Fri, 1 Jul 2011 11:06:49 -0400
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [fun] [homegate]  status of the homenet effort

Agreed. My thought was Homenet builds consensus on what work is needed and possibly sets the requirements. The development work should occur in whatever group is responsible for that technology.

Jason

-----Original Message-----
From: JP Vasseur (jvasseur) [mailto:[email-masked]]
Sent: Friday, July 01, 2011 11:02 AM
To: Ralph Droms (rdroms); Weil, Jason
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [homegate] [fun] status of the homenet effort

Agreeing with Ralph.

JP Vasseur
Cisco Fellow

Sent from Blackberry

----- Original Message -----
From: Ralph Droms (rdroms)
Sent: Friday, July 01, 2011 09:37 AM
To: Weil, Jason <[email-masked]>
Cc: Mark Townsley <[email-masked]>; JP Vasseur (jvasseur); [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [homegate] [fun] status of the homenet effort

On Jul 1, 2011, at 9:32 AM 7/1/11, Weil, Jason wrote:

>
>
> On 7/1/11 4:06 AM, "Mark Townsley" <[email-masked]> wrote:
>
>>
>> On Jul 1, 2011, at 7:27 AM, JP Vasseur (jvasseur) wrote:
>>
>>> 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?
>>
>> At least a section within a home architecture document.
>>
>>> * A recommendation for a specific routing protocol ?
>
> [JW] I see a guidelines/analysis for link-state vs. distance-vector
> routing protocols in a multi-segment home network as being useful.

In my opinion, operation without active admin intervention is more important than the particular technology.

>>> * A framework before the specification of a new routing protocol ?
>
> [JW] A framework or justification statement for a new lightweight routing
> protocol would be useful as well. A source/dest aware protocol has been
> proposed as a possible solution for the multi-homed home network for
> example.

>> The charter says:
>>
>> "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."

Source/dest aware protocol sounds more like a research project.  Developing requirements might be in scope for homenet.

- Ralph

>>
>> - Mark
>>
>>
>>> 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,
>>>>
>>>> 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 �residential home� networks. For
>>>>>> example, an obvious trend in home networking is the proliferation of
>>>>>> networking technology in an increasingly broad range and number of
>>>>>> devices. This evolution in scale and diversity sets some requirements
>>>>>> on IETF protocols. Some of the relevant trends include:
>>>>>>
>>>>>> o Multiple segments: While less complex L3-toplogies involving as few
>>>>>> subnets as possible are preferred in home networks for a variety of
>>>>>> reasons including simpler management and service discovery, the
>>>>>> introduction of more than one subnet into a home network is enough
>>>>>> to add complexity that needs to be addressed, and multiple
>>>>>> dedicated segments are necessary for some cases. For instance, a
>>>>>> common feature in modern home routers in the ability to support
>>>>>> both guest and private network segments. Also, link layer
>>>>>> networking technology is poised to become more heterogeneous, as
>>>>>> networks begin to employ both traditional Ethernet technology and
>>>>>> link layers designed for low-powered sensor networks. Finally,
>>>>>> similar needs for segmentation may occur in other cases, such as
>>>>>> separating building control or corporate extensions from the
>>>>>> Internet access network. Different segments may be associated with
>>>>>> subnets that have different routing and security policies.
>>>>>>
>>>>>> o Service providers are deploying IPv6, and support for IPv6 is
>>>>>> increasingly available in home gateway devices. While IPv6 resembles
>>>>>> IPv4 in many ways, it changes address allocation principles and
>>>>>> allows
>>>>>> direct IP addressability and routing to devices in the home from the
>>>>>> Internet. This is a promising area in IPv6 that has proved
>>>>>> challenging
>>>>>> in IPv4 with the proliferation of NAT.
>>>>>>
>>>>>> o End-to-end communication is both an opportunity and a concern as it
>>>>>> enables new applications but also exposes nodes in the internal
>>>>>> networks to receipt of unwanted traffic from the Internet. Firewalls
>>>>>> that restrict incoming connections may be used to prevent exposure,
>>>>>> however, this reduces the efficacy of end-to-end connectivity that
>>>>>> IPv6 has the potential to restore.
>>>>>>
>>>>>> Home networks need to provide the tools to handle these situations in
>>>>>> a manner accessible to all users of home networks. Manual
>>>>>> configuration is rarely, if at all, possible. The purpose of this
>>>>>> working group is to focus on this evolution, in particular as it
>>>>>> addresses the introduction of IPv6, by developing an architecture
>>>>>> addressing this full scope of requirements:
>>>>>>
>>>>>> o prefix configuration for routers
>>>>>> o managing routing
>>>>>> o name resolution
>>>>>> o service discovery
>>>>>> o network security
>>>>>>
>>>>>> The task of the group is to produce an architecture document that
>>>>>> outlines how to construct home networks involving multiple routers
>>>>>> and
>>>>>> subnets. This document is expected to apply the IPv6 addressing
>>>>>> architecture, prefix delegation, global and ULA addresses, source
>>>>>> address selection rules and other existing components of the IPv6
>>>>>> architecture. The architecture document should drive what protocols
>>>>>> changes, if any, are necessary. Specific protocol work described
>>>>>> below
>>>>>> is expected to be within the scope of the working group one the
>>>>>> architecture work is complete. However, the group is required to
>>>>>> review its charter and milestones with the IESG and IETF community
>>>>>> before submitting documents that make protocol changes. It is
>>>>>> expected
>>>>>> that the group has to discuss some of the below solutions, however,
>>>>>> in
>>>>>> order to complete the architecture work.
>>>>>>
>>>>>> The group will apply existing protocols to handle the five
>>>>>> requirements above. For prefix configuration, existing protocols are
>>>>>> likely sufficient, and at worst may need some small enhancements,
>>>>>> such
>>>>>> as new options. For automatic routing, it is expected that existing
>>>>>> routing protocols can be used as is, however, a new mechanism may be
>>>>>> needed in order to turn a selected protocol on by default. For name
>>>>>> resolution and service discovery, extensions to existing
>>>>>> multicast-based name resolution protocols are needed to enable them
>>>>>> to
>>>>>> work across subnets.
>>>>>>
>>>>>> For network security, the group shall document the concept of
>>>>>> "advanced security" as a further development of "simple security"
>>>>>> from
>>>>>> RFC 6092. The main goal of this work is to enable a security policy
>>>>>> that adapts to IPv6 threats as they emerge, taking into account not
>>>>>> only traffic from the Internet at large, but within and leaving the
>>>>>> home network itself.
>>>>>>
>>>>>> It is expected that the working group will define a set of protocol
>>>>>> specifications to accomplish the five requirements from
>>>>>> above. However, it is not in the scope of the working group to define
>>>>>> entirely new routing protocols or address allocation protocols. As
>>>>>> noted, additional options or other small extensions may be necessary
>>>>>> to use the existing protocols in these new configuration tasks. The
>>>>>> working group shall also not make any changes to IPv6 protocols or
>>>>>> addressing architecture. Prefix configuration, routing, and security
>>>>>> related work shall not cause any changes that are not backwards
>>>>>> compatible to existing IPv6 hosts. There may be host visible changes
>>>>>> in the work on naming and discovery protocols, however. In its
>>>>>> design,
>>>>>> the working group shall also consider security aspects and the impact
>>>>>> on manageability. The main focus of the working group is home
>>>>>> networks, but the group's results may also find applications in other
>>>>>> small networks.
>>>>>>
>>>>>> The working group will liaise with the relevant IETF working
>>>>>> groups. In particular, the group should work closely with the V6OPS
>>>>>> working group, review any use or extension of DHCP with the DHC
>>>>>> working group, and work with additional DNS requirements with the
>>>>>> DNSEXT and DNSOP working groups. If it turns out that additional
>>>>>> options are needed for a routing protocol, they will be developed in
>>>>>> the appropriate Routing Area working group, with the HOMENET working
>>>>>> group providing the architecture and requirements for such
>>>>>> enhancements. The working group will also liase with external
>>>>>> standards bodies where it is expected that there are normative
>>>>>> dependencies between the specifications of the two bodies.
>>>>>> It is expected that in the architecture definition stage liaising
>>>>>> with the Broadband Forum, DLNA, and UPnP Forum is necessary.
>>>>>>
>>>>>> Milestones:
>>>>>>
>>>>>> Jul 2011 Formation of the working group
>>>>>> Sep 2011 First WG draft on the architecture
>>>>>> Dec 2011 Submission of the architecture draft to the IESG as
>>>>>> Informational RFC
>>>>>> Dec 2011 Charter re-evaluation based on the architecture work
>>>>>> Dec 2011 First WG draft on prefix configuration
>>>>>> Dec 2011 First WG draft on routing
>>>>>> Jan 2012 First WG draft on name resolution
>>>>>> Feb 2012 First WG draft on service discovery
>>>>>> Feb 2012 First WG draft on perimeter security
>>>>>> Feb 2012 Start of routing related work in the relevant routing area
>>>>>> working group, if needed
>>>>>> Mar 2012 Submission of the prefix configuration draft to the IESG as
>>>>>> Standards Track RFC
>>>>>> Apr 2012 Submission of the routing draft to the IESG as Informational
>>>>>> RFC
>>>>>> Sep 2012 Submission of the name resolution draft to the IESG as
>>>>>> Standards Track RFC
>>>>>> Nov 2012 Submission of the service discovery draft to the IESG as
>>>>>> Standards Track RFC
>>>>>> Dec 2012 Submission of the perimeter security draft to the IESG as
>>>>>> Informational RFC
>>>>>>
>>>>>> _______________________________________________
>>>>>> fun mailing list
>>>>>> [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
>>>> 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
>>
>
>
> 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.
> _______________________________________________
> homegate mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homegate

Content-class: urn:content-classes:message
Date: Fri, 1 Jul 2011 10:01:30 -0500
From: "JP Vasseur (jvasseur)" <[email-masked]>
To: "Ralph Droms (rdroms)" <[email-masked]>, <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [fun] [homegate]  status of the homenet effort

Agreeing with Ralph.

JP Vasseur
Cisco Fellow

Sent from Blackberry

----- Original Message -----
From: Ralph Droms (rdroms)
Sent: Friday, July 01, 2011 09:37 AM
To: Weil, Jason <[email-masked]>
Cc: Mark Townsley <[email-masked]>; JP Vasseur (jvasseur); [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [homegate] [fun] status of the homenet effort

On Jul 1, 2011, at 9:32 AM 7/1/11, Weil, Jason wrote:

> 
> 
> On 7/1/11 4:06 AM, "Mark Townsley" <[email-masked]> wrote:
> 
>> 
>> On Jul 1, 2011, at 7:27 AM, JP Vasseur (jvasseur) wrote:
>> 
>>> 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?
>> 
>> At least a section within a home architecture document.
>> 
>>> * A recommendation for a specific routing protocol ?
> 
> [JW] I see a guidelines/analysis for link-state vs. distance-vector
> routing protocols in a multi-segment home network as being useful.

In my opinion, operation without active admin intervention is more important than the particular technology.  

>>> * A framework before the specification of a new routing protocol ?
> 
> [JW] A framework or justification statement for a new lightweight routing
> protocol would be useful as well. A source/dest aware protocol has been
> proposed as a possible solution for the multi-homed home network for
> example.

>> The charter says:
>> 
>> "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."

Source/dest aware protocol sounds more like a research project.  Developing requirements might be in scope for homenet.

- Ralph

>> 
>> - Mark
>> 
>> 
>>> 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,
>>>> 
>>>> 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 �residential home� networks. For
>>>>>> example, an obvious trend in home networking is the proliferation of
>>>>>> networking technology in an increasingly broad range and number of
>>>>>> devices. This evolution in scale and diversity sets some requirements
>>>>>> on IETF protocols. Some of the relevant trends include:
>>>>>> 
>>>>>> o Multiple segments: While less complex L3-toplogies involving as few
>>>>>> subnets as possible are preferred in home networks for a variety of
>>>>>> reasons including simpler management and service discovery, the
>>>>>> introduction of more than one subnet into a home network is enough
>>>>>> to add complexity that needs to be addressed, and multiple
>>>>>> dedicated segments are necessary for some cases. For instance, a
>>>>>> common feature in modern home routers in the ability to support
>>>>>> both guest and private network segments. Also, link layer
>>>>>> networking technology is poised to become more heterogeneous, as
>>>>>> networks begin to employ both traditional Ethernet technology and
>>>>>> link layers designed for low-powered sensor networks. Finally,
>>>>>> similar needs for segmentation may occur in other cases, such as
>>>>>> separating building control or corporate extensions from the
>>>>>> Internet access network. Different segments may be associated with
>>>>>> subnets that have different routing and security policies.
>>>>>> 
>>>>>> o Service providers are deploying IPv6, and support for IPv6 is
>>>>>> increasingly available in home gateway devices. While IPv6 resembles
>>>>>> IPv4 in many ways, it changes address allocation principles and
>>>>>> allows
>>>>>> direct IP addressability and routing to devices in the home from the
>>>>>> Internet. This is a promising area in IPv6 that has proved
>>>>>> challenging
>>>>>> in IPv4 with the proliferation of NAT.
>>>>>> 
>>>>>> o End-to-end communication is both an opportunity and a concern as it
>>>>>> enables new applications but also exposes nodes in the internal
>>>>>> networks to receipt of unwanted traffic from the Internet. Firewalls
>>>>>> that restrict incoming connections may be used to prevent exposure,
>>>>>> however, this reduces the efficacy of end-to-end connectivity that
>>>>>> IPv6 has the potential to restore.
>>>>>> 
>>>>>> Home networks need to provide the tools to handle these situations in
>>>>>> a manner accessible to all users of home networks. Manual
>>>>>> configuration is rarely, if at all, possible. The purpose of this
>>>>>> working group is to focus on this evolution, in particular as it
>>>>>> addresses the introduction of IPv6, by developing an architecture
>>>>>> addressing this full scope of requirements:
>>>>>> 
>>>>>> o prefix configuration for routers
>>>>>> o managing routing
>>>>>> o name resolution
>>>>>> o service discovery
>>>>>> o network security
>>>>>> 
>>>>>> The task of the group is to produce an architecture document that
>>>>>> outlines how to construct home networks involving multiple routers
>>>>>> and
>>>>>> subnets. This document is expected to apply the IPv6 addressing
>>>>>> architecture, prefix delegation, global and ULA addresses, source
>>>>>> address selection rules and other existing components of the IPv6
>>>>>> architecture. The architecture document should drive what protocols
>>>>>> changes, if any, are necessary. Specific protocol work described
>>>>>> below
>>>>>> is expected to be within the scope of the working group one the
>>>>>> architecture work is complete. However, the group is required to
>>>>>> review its charter and milestones with the IESG and IETF community
>>>>>> before submitting documents that make protocol changes. It is
>>>>>> expected
>>>>>> that the group has to discuss some of the below solutions, however,
>>>>>> in
>>>>>> order to complete the architecture work.
>>>>>> 
>>>>>> The group will apply existing protocols to handle the five
>>>>>> requirements above. For prefix configuration, existing protocols are
>>>>>> likely sufficient, and at worst may need some small enhancements,
>>>>>> such
>>>>>> as new options. For automatic routing, it is expected that existing
>>>>>> routing protocols can be used as is, however, a new mechanism may be
>>>>>> needed in order to turn a selected protocol on by default. For name
>>>>>> resolution and service discovery, extensions to existing
>>>>>> multicast-based name resolution protocols are needed to enable them
>>>>>> to
>>>>>> work across subnets.
>>>>>> 
>>>>>> For network security, the group shall document the concept of
>>>>>> "advanced security" as a further development of "simple security"
>>>>>> from
>>>>>> RFC 6092. The main goal of this work is to enable a security policy
>>>>>> that adapts to IPv6 threats as they emerge, taking into account not
>>>>>> only traffic from the Internet at large, but within and leaving the
>>>>>> home network itself.
>>>>>> 
>>>>>> It is expected that the working group will define a set of protocol
>>>>>> specifications to accomplish the five requirements from
>>>>>> above. However, it is not in the scope of the working group to define
>>>>>> entirely new routing protocols or address allocation protocols. As
>>>>>> noted, additional options or other small extensions may be necessary
>>>>>> to use the existing protocols in these new configuration tasks. The
>>>>>> working group shall also not make any changes to IPv6 protocols or
>>>>>> addressing architecture. Prefix configuration, routing, and security
>>>>>> related work shall not cause any changes that are not backwards
>>>>>> compatible to existing IPv6 hosts. There may be host visible changes
>>>>>> in the work on naming and discovery protocols, however. In its
>>>>>> design,
>>>>>> the working group shall also consider security aspects and the impact
>>>>>> on manageability. The main focus of the working group is home
>>>>>> networks, but the group's results may also find applications in other
>>>>>> small networks.
>>>>>> 
>>>>>> The working group will liaise with the relevant IETF working
>>>>>> groups. In particular, the group should work closely with the V6OPS
>>>>>> working group, review any use or extension of DHCP with the DHC
>>>>>> working group, and work with additional DNS requirements with the
>>>>>> DNSEXT and DNSOP working groups. If it turns out that additional
>>>>>> options are needed for a routing protocol, they will be developed in
>>>>>> the appropriate Routing Area working group, with the HOMENET working
>>>>>> group providing the architecture and requirements for such
>>>>>> enhancements. The working group will also liase with external
>>>>>> standards bodies where it is expected that there are normative
>>>>>> dependencies between the specifications of the two bodies.
>>>>>> It is expected that in the architecture definition stage liaising
>>>>>> with the Broadband Forum, DLNA, and UPnP Forum is necessary.
>>>>>> 
>>>>>> Milestones:
>>>>>> 
>>>>>> Jul 2011 Formation of the working group
>>>>>> Sep 2011 First WG draft on the architecture
>>>>>> Dec 2011 Submission of the architecture draft to the IESG as
>>>>>> Informational RFC
>>>>>> Dec 2011 Charter re-evaluation based on the architecture work
>>>>>> Dec 2011 First WG draft on prefix configuration
>>>>>> Dec 2011 First WG draft on routing
>>>>>> Jan 2012 First WG draft on name resolution
>>>>>> Feb 2012 First WG draft on service discovery
>>>>>> Feb 2012 First WG draft on perimeter security
>>>>>> Feb 2012 Start of routing related work in the relevant routing area
>>>>>> working group, if needed
>>>>>> Mar 2012 Submission of the prefix configuration draft to the IESG as
>>>>>> Standards Track RFC
>>>>>> Apr 2012 Submission of the routing draft to the IESG as Informational
>>>>>> RFC
>>>>>> Sep 2012 Submission of the name resolution draft to the IESG as
>>>>>> Standards Track RFC
>>>>>> Nov 2012 Submission of the service discovery draft to the IESG as
>>>>>> Standards Track RFC
>>>>>> Dec 2012 Submission of the perimeter security draft to the IESG as
>>>>>> Informational RFC
>>>>>> 
>>>>>> _______________________________________________
>>>>>> fun mailing list
>>>>>> [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
>>>> 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
>> 
> 
> 
> 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.
> _______________________________________________
> homegate mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homegate

From: Ralph Droms <[email-masked]>
Date: Fri, 1 Jul 2011 10:37:39 -0400
To: "Weil, Jason" <[email-masked]>
Cc: [email-masked], [email-masked], "JP Vasseur \(jvasseur\)" <[email-masked]>
Subject: Re: [fun] [homegate]  status of the homenet effort

On Jul 1, 2011, at 9:32 AM 7/1/11, Weil, Jason wrote:

> 
> 
> On 7/1/11 4:06 AM, "Mark Townsley" <[email-masked]> wrote:
> 
>> 
>> On Jul 1, 2011, at 7:27 AM, JP Vasseur (jvasseur) wrote:
>> 
>>> 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?
>> 
>> At least a section within a home architecture document.
>> 
>>> * A recommendation for a specific routing protocol ?
> 
> [JW] I see a guidelines/analysis for link-state vs. distance-vector
> routing protocols in a multi-segment home network as being useful.

In my opinion, operation without active admin intervention is more important than the particular technology.  

>>> * A framework before the specification of a new routing protocol ?
> 
> [JW] A framework or justification statement for a new lightweight routing
> protocol would be useful as well. A source/dest aware protocol has been
> proposed as a possible solution for the multi-homed home network for
> example.

>> The charter says:
>> 
>> "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."

Source/dest aware protocol sounds more like a research project.  Developing requirements might be in scope for homenet.

- Ralph

>> 
>> - Mark
>> 
>> 
>>> 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,
>>>> 
>>>> 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 �residential home� networks. For
>>>>>> example, an obvious trend in home networking is the proliferation of
>>>>>> networking technology in an increasingly broad range and number of
>>>>>> devices. This evolution in scale and diversity sets some requirements
>>>>>> on IETF protocols. Some of the relevant trends include:
>>>>>> 
>>>>>> o Multiple segments: While less complex L3-toplogies involving as few
>>>>>> subnets as possible are preferred in home networks for a variety of
>>>>>> reasons including simpler management and service discovery, the
>>>>>> introduction of more than one subnet into a home network is enough
>>>>>> to add complexity that needs to be addressed, and multiple
>>>>>> dedicated segments are necessary for some cases. For instance, a
>>>>>> common feature in modern home routers in the ability to support
>>>>>> both guest and private network segments. Also, link layer
>>>>>> networking technology is poised to become more heterogeneous, as
>>>>>> networks begin to employ both traditional Ethernet technology and
>>>>>> link layers designed for low-powered sensor networks. Finally,
>>>>>> similar needs for segmentation may occur in other cases, such as
>>>>>> separating building control or corporate extensions from the
>>>>>> Internet access network. Different segments may be associated with
>>>>>> subnets that have different routing and security policies.
>>>>>> 
>>>>>> o Service providers are deploying IPv6, and support for IPv6 is
>>>>>> increasingly available in home gateway devices. While IPv6 resembles
>>>>>> IPv4 in many ways, it changes address allocation principles and
>>>>>> allows
>>>>>> direct IP addressability and routing to devices in the home from the
>>>>>> Internet. This is a promising area in IPv6 that has proved
>>>>>> challenging
>>>>>> in IPv4 with the proliferation of NAT.
>>>>>> 
>>>>>> o End-to-end communication is both an opportunity and a concern as it
>>>>>> enables new applications but also exposes nodes in the internal
>>>>>> networks to receipt of unwanted traffic from the Internet. Firewalls
>>>>>> that restrict incoming connections may be used to prevent exposure,
>>>>>> however, this reduces the efficacy of end-to-end connectivity that
>>>>>> IPv6 has the potential to restore.
>>>>>> 
>>>>>> Home networks need to provide the tools to handle these situations in
>>>>>> a manner accessible to all users of home networks. Manual
>>>>>> configuration is rarely, if at all, possible. The purpose of this
>>>>>> working group is to focus on this evolution, in particular as it
>>>>>> addresses the introduction of IPv6, by developing an architecture
>>>>>> addressing this full scope of requirements:
>>>>>> 
>>>>>> o prefix configuration for routers
>>>>>> o managing routing
>>>>>> o name resolution
>>>>>> o service discovery
>>>>>> o network security
>>>>>> 
>>>>>> The task of the group is to produce an architecture document that
>>>>>> outlines how to construct home networks involving multiple routers
>>>>>> and
>>>>>> subnets. This document is expected to apply the IPv6 addressing
>>>>>> architecture, prefix delegation, global and ULA addresses, source
>>>>>> address selection rules and other existing components of the IPv6
>>>>>> architecture. The architecture document should drive what protocols
>>>>>> changes, if any, are necessary. Specific protocol work described
>>>>>> below
>>>>>> is expected to be within the scope of the working group one the
>>>>>> architecture work is complete. However, the group is required to
>>>>>> review its charter and milestones with the IESG and IETF community
>>>>>> before submitting documents that make protocol changes. It is
>>>>>> expected
>>>>>> that the group has to discuss some of the below solutions, however,
>>>>>> in
>>>>>> order to complete the architecture work.
>>>>>> 
>>>>>> The group will apply existing protocols to handle the five
>>>>>> requirements above. For prefix configuration, existing protocols are
>>>>>> likely sufficient, and at worst may need some small enhancements,
>>>>>> such
>>>>>> as new options. For automatic routing, it is expected that existing
>>>>>> routing protocols can be used as is, however, a new mechanism may be
>>>>>> needed in order to turn a selected protocol on by default. For name
>>>>>> resolution and service discovery, extensions to existing
>>>>>> multicast-based name resolution protocols are needed to enable them
>>>>>> to
>>>>>> work across subnets.
>>>>>> 
>>>>>> For network security, the group shall document the concept of
>>>>>> "advanced security" as a further development of "simple security"
>>>>>> from
>>>>>> RFC 6092. The main goal of this work is to enable a security policy
>>>>>> that adapts to IPv6 threats as they emerge, taking into account not
>>>>>> only traffic from the Internet at large, but within and leaving the
>>>>>> home network itself.
>>>>>> 
>>>>>> It is expected that the working group will define a set of protocol
>>>>>> specifications to accomplish the five requirements from
>>>>>> above. However, it is not in the scope of the working group to define
>>>>>> entirely new routing protocols or address allocation protocols. As
>>>>>> noted, additional options or other small extensions may be necessary
>>>>>> to use the existing protocols in these new configuration tasks. The
>>>>>> working group shall also not make any changes to IPv6 protocols or
>>>>>> addressing architecture. Prefix configuration, routing, and security
>>>>>> related work shall not cause any changes that are not backwards
>>>>>> compatible to existing IPv6 hosts. There may be host visible changes
>>>>>> in the work on naming and discovery protocols, however. In its
>>>>>> design,
>>>>>> the working group shall also consider security aspects and the impact
>>>>>> on manageability. The main focus of the working group is home
>>>>>> networks, but the group's results may also find applications in other
>>>>>> small networks.
>>>>>> 
>>>>>> The working group will liaise with the relevant IETF working
>>>>>> groups. In particular, the group should work closely with the V6OPS
>>>>>> working group, review any use or extension of DHCP with the DHC
>>>>>> working group, and work with additional DNS requirements with the
>>>>>> DNSEXT and DNSOP working groups. If it turns out that additional
>>>>>> options are needed for a routing protocol, they will be developed in
>>>>>> the appropriate Routing Area working group, with the HOMENET working
>>>>>> group providing the architecture and requirements for such
>>>>>> enhancements. The working group will also liase with external
>>>>>> standards bodies where it is expected that there are normative
>>>>>> dependencies between the specifications of the two bodies.
>>>>>> It is expected that in the architecture definition stage liaising
>>>>>> with the Broadband Forum, DLNA, and UPnP Forum is necessary.
>>>>>> 
>>>>>> Milestones:
>>>>>> 
>>>>>> Jul 2011 Formation of the working group
>>>>>> Sep 2011 First WG draft on the architecture
>>>>>> Dec 2011 Submission of the architecture draft to the IESG as
>>>>>> Informational RFC
>>>>>> Dec 2011 Charter re-evaluation based on the architecture work
>>>>>> Dec 2011 First WG draft on prefix configuration
>>>>>> Dec 2011 First WG draft on routing
>>>>>> Jan 2012 First WG draft on name resolution
>>>>>> Feb 2012 First WG draft on service discovery
>>>>>> Feb 2012 First WG draft on perimeter security
>>>>>> Feb 2012 Start of routing related work in the relevant routing area
>>>>>> working group, if needed
>>>>>> Mar 2012 Submission of the prefix configuration draft to the IESG as
>>>>>> Standards Track RFC
>>>>>> Apr 2012 Submission of the routing draft to the IESG as Informational
>>>>>> RFC
>>>>>> Sep 2012 Submission of the name resolution draft to the IESG as
>>>>>> Standards Track RFC
>>>>>> Nov 2012 Submission of the service discovery draft to the IESG as
>>>>>> Standards Track RFC
>>>>>> Dec 2012 Submission of the perimeter security draft to the IESG as
>>>>>> Informational RFC
>>>>>> 
>>>>>> _______________________________________________
>>>>>> fun mailing list
>>>>>> [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
>>>> 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
>> 
> 
> 
> 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.
> _______________________________________________
> homegate mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homegate

From: Keith Moore <[email-masked]>
Date: Fri, 1 Jul 2011 09:35:53 -0400
To: Mark Townsley <[email-masked]>
Cc: IETF Discussion <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [fun] [homegate] HOMENET working group proposal

On Jul 1, 2011, at 4:53 AM, Mark Townsley wrote:

> The idea is not to go out of our way for IPv4, but if the topic is IP agnostic anyway, so be it. To be clear, there is no *requirement* to support IPv4 here. However, there is no requirement to avoid IPv4 *if* it doesn't cause significant concession in the IPv6 design either.
> 
> This cuts both ways, if there is something that is working well in IPv4 that we need to carry over to IPv6 with simple extensions, we'll do that and capitalizing on that running-code should be considered a good thing. We don't want to invent new v6 protocols from scratch that don't work with IPv4 when there is no need. For example (and I think this is hinted at in the charter), we might use naming and service discovery that already exists for IPv4, adapted the the v6 homenet. This doesn't mean we need to re-invent a v6-only naming system from scratch - i'd much rather use one that is there, which very well may support v4 and v6. 
> 
>> 
>> please don't constrain home networks to work only within the confines of IPv4 brain damage.
> 
> What I think I am saying here is that we will do our best to perform as if our brains are not damaged, and equally try to avoid damaging our brains in the process.

+1

Keith

From: "Weil, Jason" <[email-masked]>
To: Mark Townsley <[email-masked]>, "JP Vasseur (jvasseur)" <[email-masked]>
Date: Fri, 1 Jul 2011 09:32:11 -0400
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [fun] status of the homenet effort

From: Mark Townsley <[email-masked]>
Date: Fri, 1 Jul 2011 14:19:12 +0200
To: [email-masked]
Cc: [email-masked]
Subject: Re: [fun] status of the homenet effort

On Jul 1, 2011, at 1:45 PM, Robert Raszuk wrote:

> While rereading the proposed charter I have two questions ..
> 
> 1. Is documentation or new tools specification development for home network troubleshooting either manual or automated in or outside of charter ? How about diagnostics in reachability to internal subnets or different hosts on the internet ?

That's a pretty broad question. Let me try and answer. 

There is a prevailing notion that the home network must work well in a "not actively managed" manner. So if we met our goal perfectly, we'd need no troubleshooting or diagnostics tools. The world isn't perfect though, and where tools and such are necessary I'm sure they will spring up. I don't see these specifically as major deliverables for homenet though. 

Note that protocols themselves, in particular auto-configuration and such, are by their nature doing "automatic trouble-shooting" in one form or another, and in terms of "reachability" IPv6 has NUD built right in at least for within the home. So, in as much as this is part and parcel for the protocol to work in an "automatic" and "not actively managed" manner, sure, homenet has that. If you mean defining a "home network management" application? No, I don't think we're going there.  I could imagine a homenet-ops or some such in the future, or as part of v6ops now, that could develop these more though. 

> 2. How about multihoming with seamless switchover ?

This particular elephant has been in and out of various versions of the charter. I'll plead the 5th on this one and ask Jari to describe where we are on this, in particular in relation to mif, shim6, lisp, rrg, v6ops, or any of the other areas that are touching on this. 

Personally, I think it would be naive to not include the various possibilities of multihomed connectivity, at the vary least in describing the architecture for which we will work within. I don't think homenet is the place to solve the general issue of "seamless multihoming" at the protocol level, but perhaps we would point to what works well in a home setting... we might even agree to one way to do it if we are really, really, lucky. 

> I think those will make home networking a bit easier ?
> 
> ---
> 
> Example for 1: What happens if I can ping/trace a destination, browse it's web site just fine, but my cgi script dies ? And I have a real case like this which honestly I am not sure how to troubleshoot. Server side reports no errors at all in the log. MTU is low as it can be.
> 
> /* Well I found the solution but will not say it on this list as I am afraid Jari and Mark will unsubscribe me ;-) */

I doubt that. 

- Mark

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

Date: Fri, 01 Jul 2011 13:45:49 +0200
From: Robert Raszuk <[email-masked]>
To: [email-masked]
Subject: Re: [fun] status of the homenet effort
Reply-To: [email-masked]

While rereading the proposed charter I have two questions ..

1. Is documentation or new tools specification development for home 
network troubleshooting either manual or automated in or outside of 
charter ? How about diagnostics in reachability to internal subnets or 
different hosts on the internet ?

2. How about multihoming with seamless switchover ?

I think those will make home networking a bit easier ?

---

Example for 1: What happens if I can ping/trace a destination, browse 
it's web site just fine, but my cgi script dies ? And I have a real case 
like this which honestly I am not sure how to troubleshoot. Server side 
reports no errors at all in the log. MTU is low as it can be.

/* Well I found the solution but will not say it on this list as I am 
afraid Jari and Mark will unsubscribe me ;-) */

Cheers,
R.

From: Mark Townsley <[email-masked]>
Date: Fri, 1 Jul 2011 12:31:00 +0200
To: Mikael Abrahamsson <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [fun] status of the homenet effort

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

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

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

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

- Mark

> 
> <http://www.dlna.org/about_us/faqs/>
> 
> "The DLNA Guidelines are available to DLNA Member companies for free and to purchase for non-DLNA Members."
> 
> -- 
> Mikael Abrahamsson    email: [email-masked]
> _______________________________________________
> fun mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/fun

Date: Fri, 1 Jul 2011 12:19:59 +0200 (CEST)
From: Mikael Abrahamsson <[email-masked]>
To: Daniel Park <[email-masked]>
Organization: People's Front Against WWW
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [fun] status of the homenet effort

On Fri, 1 Jul 2011, Daniel Park wrote:

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

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

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

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

-- 
Mikael Abrahamsson    email: [email-masked]

Date: Fri, 1 Jul 2011 18:31:09 +0900
From: Daniel Park <[email-masked]>
To: Jari Arkko <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [fun] status of the homenet effort

--0016e659fcec83d51604a6fead96
Content-Type: text/plain; charset=EUC-KR
Content-Transfer-Encoding: quoted-printable

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

Daniel

Soohong Daniel Park
from Galaxy S, twitter: @natpt
2011. 7. 1. ���� 6:15�� "Jari Arkko" <[email-masked]>���� �ۼ�:
> Daniel,
>> Presumably, the architrcture includes an analysis work considering the
current home networking solutions, particulary DLNA. Correct? In fact, DLNA
did the IPv6 over DLNA work before through a IPv6 Task Force, and came up
with the whitepaper several years back. IPv6 is not well and widely embedded
into DLNA yet though. Just curious how interop and harmonize between ietf
work and DLNA. The past DLAN deliverable/efforts might be referred, and used
for this Homenet work.
>>
>
> Yes. There needs to be an awareness and analysis of everything that
> already exists -- DHCP components, V6OPS documents on simple security,
> DLNA work, UPnP work, etc.
>
> Do you have a reference to the whitepaper and other associated
> information at DLNA?
>
> Jari
>

--0016e659fcec83d51604a6fead96
Content-Type: text/html; charset=EUC-KR
Content-Transfer-Encoding: quoted-printable

<p>Yes, since I was also a member of that TF within DLNA. But, I do not quite sure now whether we can&nbsp; share that whitepaper in ietf due to DLNA membership policy.</p>
<p>Daniel</p>
<p>Soohong Daniel Park<br>
from Galaxy S, twitter: @natpt</p>
<div class="gmail_quote">2011. 7. 1. ���� 6:15�� &quot;Jari Arkko&quot; &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;���� �ۼ�:<br type="attribution">&gt; Daniel,<br>&gt;&gt; Presumably, the architrcture includes an analysis work considering the current home networking solutions, particulary DLNA. Correct? In fact, DLNA did the IPv6 over DLNA work before through a IPv6 Task Force, and came up with the whitepaper several years back. IPv6 is not well and widely embedded into DLNA yet though. Just curious how interop and harmonize between ietf work and DLNA. The past DLAN deliverable/efforts might be referred, and used for this Homenet work.<br>
&gt;&gt;   <br>&gt; <br>&gt; Yes. There needs to be an awareness and analysis of everything that <br>&gt; already exists -- DHCP components, V6OPS documents on simple security, <br>&gt; DLNA work, UPnP work, etc.<br>&gt; <br>
&gt; Do you have a reference to the whitepaper and other associated <br>&gt; information at DLNA?<br>&gt; <br>&gt; Jari<br>&gt; <br></div>

--0016e659fcec83d51604a6fead96--

Date: Fri, 01 Jul 2011 11:15:22 +0200
From: Jari Arkko <[email-masked]>
To: Soohong Daniel Park <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [fun] status of the homenet effort

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

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

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

Jari

From: Soohong Daniel Park <[email-masked]>
Date: Fri, 1 Jul 2011 18:01:12 +0900
To: Jari Arkko <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [fun] status of the homenet effort

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

Daniel,

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

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

> This is just an update that the IESG approved the below charter for external review in its meeting today. "For external review" means that IETF participants and other people are formally asked to comment on it. The review period runs until July 14th.
> 
> Jari
> 
> Home Networks (homenet)
> -----------------------------------
> 
> Current Status: Proposed
> Last Edit: Wednesday, June 30th, 2011
> 
> Chairs:
> TBD
> 
> Internet Area Directors:
> Ralph Droms <[email-masked]>
> Jari Arkko <[email-masked]>
> 
> Internet Area Advisor:
> Jari Arkko <[email-masked]>
> 
> Routing Area Technical Advisor:
> TBD
> 
> Security Area Technical Advisor:
> TBD
> 
> Mailing Lists:
> General Discussion: [email-masked]
> To Subscribe: https://www.ietf.org/mailman/listinfo/fun
> Archive: http://www.ietf.org/mail-archive/web/fun
> 
> Description of Working Group:
> 
> This working group focuses on the evolving networking technology
> within and among relatively small “residential home” networks. For
> example, an obvious trend in home networking is the proliferation of
> networking technology in an increasingly broad range and number of
> devices. This evolution in scale and diversity sets some requirements
> on IETF protocols. Some of the relevant trends include:
> 
> o  Multiple segments: While less complex L3-toplogies involving as few
>  subnets as possible are preferred in home networks for a variety of
>  reasons including simpler management and service discovery, the
>  introduction of more than one subnet into a home network is enough
>  to add complexity that needs to be addressed, and multiple
>  dedicated segments are necessary for some cases.  For instance, a
>  common feature in modern home routers in the ability to support
>  both guest and private network segments. Also, link layer
>  networking technology is poised to become more heterogeneous, as
>  networks begin to employ both traditional Ethernet technology and
>  link layers designed for low-powered sensor networks. Finally,
>  similar needs for segmentation may occur in other cases, such as
>  separating building control or corporate extensions from the
>  Internet access network. Different segments may be associated with
>  subnets that have different routing and security policies.
> 
> o  Service providers are deploying IPv6, and support for IPv6 is
>  increasingly available in home gateway devices. While IPv6 resembles
>  IPv4 in many ways, it changes address allocation principles and allows
>  direct IP addressability and routing to devices in the home from the
>  Internet. This is a promising area in IPv6 that has proved challenging
>  in IPv4 with the proliferation of NAT.
> 
> o  End-to-end communication is both an opportunity and a concern as it
>  enables new applications but also exposes nodes in the internal
>  networks to receipt of unwanted traffic from the Internet. Firewalls
>  that restrict incoming connections may be used to prevent exposure,
>  however, this reduces the efficacy of end-to-end connectivity that
>  IPv6 has the potential to restore.
> 
> Home networks need to provide the tools to handle these situations in
> a manner accessible to all users of home networks. Manual
> configuration is rarely, if at all, possible, as the necessary skills
> and in some cases even suitable management interfaces are missing.
> 
> The purpose of this working group is to focus on this evolution, in
> particular as it addresses the introduction of IPv6, by developing an
> architecture addressing this full scope of requirements:
> 
> o  prefix configuration for routers
> o  managing routing
> o  name resolution
> o  service discovery
> o  network security
> 
> The task of the group is to produce an architecture document that
> outlines how to construct home networks involving multiple routers and
> subnets. This document is expected to apply the IPv6 addressing
> architecture, prefix delegation, global and ULA addresses, source
> address selection rules and other existing components of the IPv6
> architecture. The architecture document should drive what protocols
> changes, if any, are necessary. Specific protocol work described below
> is expected to be within the scope of the working group once the
> architecture work is complete. However, the group is required to
> review its charter and milestones with the IESG and IETF community
> before submitting documents that make protocol changes. It is expected
> that the group has to discuss some of the below solutions, however, in
> order to complete the architecture work.
> 
> The group will apply existing protocols to handle the five
> requirements above. For prefix configuration, existing protocols are
> likely sufficient, and at worst may need some small enhancements, such
> as new options. For automatic routing, it is expected that existing
> routing protocols can be used as is, however, a new mechanism may be
> needed in order to turn a selected protocol on by default. For name
> resolution and service discovery, extensions to existing
> multicast-based name resolution protocols are needed to enable them to
> work across subnets.
> 
> For network security, the group shall document the concept of
> "advanced security" as a further development of "simple security" from
> RFC 6092. The main goal of this work is to enable a security policy
> that adapts to IPv6 threats as they emerge, taking into account not
> only traffic from the Internet at large, but within and leaving the
> home network itself.
> 
> It is expected that the working group will define a set of protocol
> specifications to accomplish the five requirements from
> above. However, it is not in the scope of the working group to define
> entirely new routing protocols or address allocation protocols. As
> noted, additional options or other small extensions may be necessary
> to use the existing protocols in these new configuration tasks. The
> working group shall also not make any changes to IPv6 protocols or
> addressing architecture. Prefix configuration, routing, and security
> related work shall not cause any changes that are not backwards
> compatible to existing IPv6 hosts. There may be host visible changes
> in the work on naming and discovery protocols, however. In its design,
> the working group shall also consider security aspects and the impact
> on manageability. The main focus of the working group is home
> networks, but the group's results may also find applications in other
> small networks.
> 
> The working group will liaise with the relevant IETF working
> groups. In particular, the group should work closely with the V6OPS
> working group, review any use or extension of DHCP with the DHC
> working group, and work with additional DNS requirements with the
> DNSEXT and DNSOP working groups. If it turns out that additional
> options are needed for a routing protocol, they will be developed in
> the appropriate Routing Area working group, with the HOMENET working
> group providing the architecture and requirements for such
> enhancements. The working group will also liase with external
> standards bodies where it is expected that there are normative
> dependencies between the specifications of the two bodies.
> It is expected that in the architecture definition stage liaising
> with the Broadband Forum, DLNA, and UPnP Forum is necessary.
> 
> Milestones:
> 
> Jul 2011 Formation of the working group
> Sep 2011 First WG draft on the architecture
> Dec 2011 Submission of the architecture draft to the IESG as Informational RFC
> Dec 2011 Charter re-evaluation based on the architecture work
> Dec 2011 First WG draft on prefix configuration
> Dec 2011 First WG draft on routing
> Jan 2012 First WG draft on name resolution
> Feb 2012 First WG draft on service discovery
> Feb 2012 First WG draft on perimeter security
> Feb 2012 Start of routing related work in the relevant routing area working group, if needed
> Mar 2012 Submission of the prefix configuration draft to the IESG as Standards Track RFC
> Apr 2012 Submission of the routing draft to the IESG as Informational RFC
> Sep 2012 Submission of the name resolution draft to the IESG as Standards Track RFC
> Nov 2012 Submission of the service discovery draft to the IESG as Standards Track RFC
> Dec 2012 Submission of the perimeter security draft to the IESG as Informational RFC
> 
> _______________________________________________
> fun mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/fun

From: Mark Townsley <[email-masked]>
Date: Fri, 1 Jul 2011 10:53:37 +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 6:36 PM, Keith Moore wrote:

> On Jun 30, 2011, at 12:33 PM, 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
>>> 
>>> 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. 
>> 
>> My original mail had this restatement of the above, which I think gets closer to what you want:
>> 
>>>> However, when we can define something that is needed for IPv6 in a way that is also useful for IPv4 without making significant concessions, we should go ahead and do so.
> 
> when the group can define something that is useful in IPv6, it shouldn't matter whether it's also useful for IPv4.

The idea is not to go out of our way for IPv4, but if the topic is IP agnostic anyway, so be it. To be clear, there is no *requirement* to support IPv4 here. However, there is no requirement to avoid IPv4 *if* it doesn't cause significant concession in the IPv6 design either.

This cuts both ways, if there is something that is working well in IPv4 that we need to carry over to IPv6 with simple extensions, we'll do that and capitalizing on that running-code should be considered a good thing. We don't want to invent new v6 protocols from scratch that don't work with IPv4 when there is no need. For example (and I think this is hinted at in the charter), we might use naming and service discovery that already exists for IPv4, adapted the the v6 homenet. This doesn't mean we need to re-invent a v6-only naming system from scratch - i'd much rather use one that is there, which very well may support v4 and v6. 

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

What I think I am saying here is that we will do our best to perform as if our brains are not damaged, and equally try to avoid damaging our brains in the process.

- Mark

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

From: Mark Townsley <[email-masked]>
Date: Fri, 1 Jul 2011 10:06:46 +0200
To: "JP Vasseur (jvasseur)" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [fun] status of the homenet effort

On Jul 1, 2011, at 7:27 AM, JP Vasseur (jvasseur) wrote:

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

At least a section within a home architecture document.

> * A recommendation for a specific routing protocol ?

> * A framework before the specification of a new routing protocol ?

The charter says:

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

- Mark

> 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,
>> 
>> 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 �residential home� networks. For
>>>> example, an obvious trend in home networking is the proliferation of
>>>> networking technology in an increasingly broad range and number of
>>>> devices. This evolution in scale and diversity sets some requirements
>>>> on IETF protocols. Some of the relevant trends include:
>>>> 
>>>> o Multiple segments: While less complex L3-toplogies involving as few
>>>> subnets as possible are preferred in home networks for a variety of
>>>> reasons including simpler management and service discovery, the
>>>> introduction of more than one subnet into a home network is enough
>>>> to add complexity that needs to be addressed, and multiple
>>>> dedicated segments are necessary for some cases. For instance, a
>>>> common feature in modern home routers in the ability to support
>>>> both guest and private network segments. Also, link layer
>>>> networking technology is poised to become more heterogeneous, as
>>>> networks begin to employ both traditional Ethernet technology and
>>>> link layers designed for low-powered sensor networks. Finally,
>>>> similar needs for segmentation may occur in other cases, such as
>>>> separating building control or corporate extensions from the
>>>> Internet access network. Different segments may be associated with
>>>> subnets that have different routing and security policies.
>>>> 
>>>> o Service providers are deploying IPv6, and support for IPv6 is
>>>> increasingly available in home gateway devices. While IPv6 resembles
>>>> IPv4 in many ways, it changes address allocation principles and allows
>>>> direct IP addressability and routing to devices in the home from the
>>>> Internet. This is a promising area in IPv6 that has proved challenging
>>>> in IPv4 with the proliferation of NAT.
>>>> 
>>>> o End-to-end communication is both an opportunity and a concern as it
>>>> enables new applications but also exposes nodes in the internal
>>>> networks to receipt of unwanted traffic from the Internet. Firewalls
>>>> that restrict incoming connections may be used to prevent exposure,
>>>> however, this reduces the efficacy of end-to-end connectivity that
>>>> IPv6 has the potential to restore.
>>>> 
>>>> Home networks need to provide the tools to handle these situations in
>>>> a manner accessible to all users of home networks. Manual
>>>> configuration is rarely, if at all, possible. The purpose of this
>>>> working group is to focus on this evolution, in particular as it
>>>> addresses the introduction of IPv6, by developing an architecture
>>>> addressing this full scope of requirements:
>>>> 
>>>> o prefix configuration for routers
>>>> o managing routing
>>>> o name resolution
>>>> o service discovery
>>>> o network security
>>>> 
>>>> The task of the group is to produce an architecture document that
>>>> outlines how to construct home networks involving multiple routers and
>>>> subnets. This document is expected to apply the IPv6 addressing
>>>> architecture, prefix delegation, global and ULA addresses, source
>>>> address selection rules and other existing components of the IPv6
>>>> architecture. The architecture document should drive what protocols
>>>> changes, if any, are necessary. Specific protocol work described below
>>>> is expected to be within the scope of the working group one the
>>>> architecture work is complete. However, the group is required to
>>>> review its charter and milestones with the IESG and IETF community
>>>> before submitting documents that make protocol changes. It is expected
>>>> that the group has to discuss some of the below solutions, however, in
>>>> order to complete the architecture work.
>>>> 
>>>> The group will apply existing protocols to handle the five
>>>> requirements above. For prefix configuration, existing protocols are
>>>> likely sufficient, and at worst may need some small enhancements, such
>>>> as new options. For automatic routing, it is expected that existing
>>>> routing protocols can be used as is, however, a new mechanism may be
>>>> needed in order to turn a selected protocol on by default. For name
>>>> resolution and service discovery, extensions to existing
>>>> multicast-based name resolution protocols are needed to enable them to
>>>> work across subnets.
>>>> 
>>>> For network security, the group shall document the concept of
>>>> "advanced security" as a further development of "simple security" from
>>>> RFC 6092. The main goal of this work is to enable a security policy
>>>> that adapts to IPv6 threats as they emerge, taking into account not
>>>> only traffic from the Internet at large, but within and leaving the
>>>> home network itself.
>>>> 
>>>> It is expected that the working group will define a set of protocol
>>>> specifications to accomplish the five requirements from
>>>> above. However, it is not in the scope of the working group to define
>>>> entirely new routing protocols or address allocation protocols. As
>>>> noted, additional options or other small extensions may be necessary
>>>> to use the existing protocols in these new configuration tasks. The
>>>> working group shall also not make any changes to IPv6 protocols or
>>>> addressing architecture. Prefix configuration, routing, and security
>>>> related work shall not cause any changes that are not backwards
>>>> compatible to existing IPv6 hosts. There may be host visible changes
>>>> in the work on naming and discovery protocols, however. In its design,
>>>> the working group shall also consider security aspects and the impact
>>>> on manageability. The main focus of the working group is home
>>>> networks, but the group's results may also find applications in other
>>>> small networks.
>>>> 
>>>> The working group will liaise with the relevant IETF working
>>>> groups. In particular, the group should work closely with the V6OPS
>>>> working group, review any use or extension of DHCP with the DHC
>>>> working group, and work with additional DNS requirements with the
>>>> DNSEXT and DNSOP working groups. If it turns out that additional
>>>> options are needed for a routing protocol, they will be developed in
>>>> the appropriate Routing Area working group, with the HOMENET working
>>>> group providing the architecture and requirements for such
>>>> enhancements. The working group will also liase with external
>>>> standards bodies where it is expected that there are normative
>>>> dependencies between the specifications of the two bodies.
>>>> It is expected that in the architecture definition stage liaising
>>>> with the Broadband Forum, DLNA, and UPnP Forum is necessary.
>>>> 
>>>> Milestones:
>>>> 
>>>> Jul 2011 Formation of the working group
>>>> Sep 2011 First WG draft on the architecture
>>>> Dec 2011 Submission of the architecture draft to the IESG as
>>>> Informational RFC
>>>> Dec 2011 Charter re-evaluation based on the architecture work
>>>> Dec 2011 First WG draft on prefix configuration
>>>> Dec 2011 First WG draft on routing
>>>> Jan 2012 First WG draft on name resolution
>>>> Feb 2012 First WG draft on service discovery
>>>> Feb 2012 First WG draft on perimeter security
>>>> Feb 2012 Start of routing related work in the relevant routing area
>>>> working group, if needed
>>>> Mar 2012 Submission of the prefix configuration draft to the IESG as
>>>> Standards Track RFC
>>>> Apr 2012 Submission of the routing draft to the IESG as Informational
>>>> RFC
>>>> Sep 2012 Submission of the name resolution draft to the IESG as
>>>> Standards Track RFC
>>>> Nov 2012 Submission of the service discovery draft to the IESG as
>>>> Standards Track RFC
>>>> Dec 2012 Submission of the perimeter security draft to the IESG as
>>>> Informational RFC
>>>> 
>>>> _______________________________________________
>>>> fun mailing list
>>>> [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 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: Mark Townsley <[email-masked]>
Date: Fri, 1 Jul 2011 10:01:59 +0200
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [fun] [homegate] HOMENET working group proposal

--Apple-Mail-1-487637714
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Jul 1, 2011, at 1:10 AM, Robert Raszuk wrote:

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

My ISP has v6 to a half-million homes and doesn't know how to deal with multiple v6 subnets (among other things) aside of manual configuration. But let's stay out of "my ISP says" discussions. Clearly, we can come up with anecdotes at every extreme. What's important is that, globally, IPv6 deployment is finally on the rise and implementations are appearing in commercial products targeted at the home. 

You are probably running IPv6 in your home anyway if you have a Mac, linux, or windows machine circa Vista or later. It may be disconnected from the Internet (or is possibly connected via some automatic tunnel that you may or may not be aware of), but even link-local IPv6 in the home is something that should work correctly. 

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

There are technical issues with deploying IPv6 in the home, and that is what homenet is slated to work on. 

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

Ah yes, the Killer App - it would all too easy if IPv6 had a visicalc or wordstar equivalent to drive sales, wouldn't it? 

http://en.wikipedia.org/wiki/Killer_application

That discussion is not really within the scope of this WG though.

- Mark

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

--Apple-Mail-1-487637714
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jul 1, 2011, at 1:10 AM, Robert Raszuk wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div><br>I think this is a great WG proposal and I fully support it's creation.<br><br>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.<br></div></blockquote><div><br></div><div>My ISP has v6 to a half-million homes and doesn't know how to deal with multiple v6 subnets (among other things) aside of manual configuration.&nbsp;But let's stay out of "my ISP says" discussions. Clearly, we can come up with anecdotes at every extreme. What's important is that, globally, IPv6 deployment is finally on the rise and implementations are appearing in commercial products targeted at the home.&nbsp;</div><div><br></div><div>You are probably running IPv6 in your home anyway if you have a Mac, linux, or windows machine circa Vista or later. It may be disconnected from the Internet (or is possibly connected via some automatic tunnel that you may or may not be aware of), but even link-local IPv6 in the home is something that should work correctly.&nbsp;</div><br><blockquote type="cite"><div><br>IETF can build many specs recommending v6 deployments, protocol extensions and network architectures. Unfortunately before the day &nbsp;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.<br><br>The issue is not technical here and IETF will not I am afraid be able to fix it.<br></div></blockquote><div><br></div><div>There are technical issues with deploying IPv6 in the home, and that is what homenet is slated to work on.&nbsp;</div><br><blockquote type="cite"><div>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.</div></blockquote><div><br></div><div>Ah yes, the Killer App - it would all too easy if IPv6 had a visicalc or wordstar equivalent to drive sales, wouldn't it?&nbsp;</div><div><br></div><div><a href="http://en.wikipedia.org/wiki/Killer_application">http://en.wikipedia.org/wiki/Killer_application</a></div><div><br></div><div>That discussion is not really within the scope of this WG though.</div><div><br></div><div>- Mark</div><br><blockquote type="cite"><div><br>Cheers,<br>R.<br>_______________________________________________<br>fun mailing list<br><a href="mailto:[email-masked]">[email-masked]</a><br>https://www.ietf.org/mailman/listinfo/fun<br></div></blockquote></div><br></body></html>
--Apple-Mail-1-487637714--

From [email-masked]  Tue Jul  5 12:28:07 2011
Date: Tue, 05 Jul 2011 22:28:00 +0300
From: Jari Arkko <[email-masked]>
To: Keith Moore <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [homenet] [fun] WG Review: Home Networks (homenet)

Keith,

Thanks for your comments. One quick response:

>> 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.
>>     
>
> I don't think it should be presumed that ULA's are applicable.  Perhaps, but not certainly.  ULAs should be limited to devices for which there is never any need to be accessed from outside the network, or to access external hosts, and offhand I can't think of a situation that makes it reasonable to impose this limitation on every device on a network segment..  If ULAs can be doled out to only those devices that do not have permission for external access, independent of network segment, that might be fine. 
>   

I do not think it should be presumed either. The text in the charter is
trying to say that IPv6 to its full extent should be used.

That being said, RFC 6204 (a previous product of the IETF in this space)
does speak about them.

Jari

From [email-masked]  Wed Jul  6 08:31:04 2011
From: Mark Townsley <[email-masked]>
Date: Wed, 6 Jul 2011 17:30:43 +0200
To: [email-masked]
Cc: Christopher Palmer <[email-masked]>
Subject: Re: [homenet] Feedback - HomeNet Charter

--Apple-Mail-15-946561602
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

On Jul 2, 2011, at 12:52 AM, Christopher Palmer wrote:

> Hey Folks,
>  
> I�ve been trying to keep track of all the feedback concerning the HomeNet Charter. Sorry for bringing up points that may have been discussed before, or are in general noobish.
>  
> �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.�
>  
> We are absolutely aligned to this objective. IPv6 provides an opportunity to avoid the limiting topology of current IPv4 deployments and this should a priority for everyone in the technology community.
>  
> I have points of concern. �Managing routing� is a very broad category of things and I�m not clear about what the vision is there.

Perhaps it is a bad title,  but the point that should be clear in the supporting text is that there are existing mechanisms for which each could do a nice job at routing across multiple segments within a v6-enabled homenet, but the pieces need to come together in a way that can be managed by a home user (which we assume will not actively manage anything).

>  
> The focus on multiple subnet solutions doesn�t seemed align to current operational reality. While I understand the desire to be forward looking, this seems �very� forward looking to a point. I�d be interested in data that reflects the contrary.

Please see:

http://tools.ietf.org/html/draft-herbst-v6ops-cpeenhancements-00
http://tools.ietf.org/html/draft-baker-fun-multi-router-00

> Windows and Apple currently use different mechanisms for service discovery. Is unification a goal? WSD is managed by OASIS, which isn�t mentioned for liasoning. Would we imagine the multicast DNS draft moving over to this WG? I�m just confused on what is happening and what is intended to happen. While the charter says routing changes will be handled by the routing area working group, the charter is not that specific on DNS changes.

There are two aspects here that are clearly in scope:

One, is figuring out when and how to allow service discovery to reach all services in the home rather than just those on a given link-local-scope. This I believe certainly applies to mDNS, and it might to OASIS. I mentioned in another post that it is certainly much easier when an SDO that the IETF works with has a more open policy, but even when an SDO has a rather closed default policy that arrangements are often possible. This of course requires both willingness on behalf of the partnering SDO, as well as an individual in the IETF who cares enough to make it happen (which I suppose in this case would be you!). 

The other is service discovery itself for home routers. Certainly, a homenet router has its own services to advertise, the most basic of which would be a configuration interface. Traditionally with IPv4, the most basic method for this has been by typing in something like a 192.168.1.1 literal in a web browser. This of course is something that is not possible with IPv6 - not only because IPv6 addresses are difficult for humans to type, but because  there is no private space to choose an address from. Also, with more than one router in the home and no possibility of overlapping address space, we need a way to manage more than one router at a time (or at least know which one we are managing). 

I'm not certain we want to get into taking on standardization of service discovery far beyond this in homenet itself, not to say I would not love to see a world where multivendor (including Windows and Apple) service discovery standardized on the same mechanism and worked in a far more consistent manner.
 
> I feel like the vision and defining principles could be spelled out more. We want IPv6 home networks to be routable. OK.  What else do we want? Why are we doing this?

The main point is that IPv6 brings issues in home networks that do not fit into the singleton model of single-router, single-link, single-subnet, single-ISP. Those issues in IPv4 will in some cases be overcome with NAT and private addressing, and in some cases will simply not be overcome (at least not at the network level) because the effort to do so in IPv4 is too great. In IPv6, we'd like to not resort to NAT, we'd like to turn on firewall-type security only where it makes sense, etc. -  ultimately we'd like the IPv6 homenet to actually work better than the status quo today with IPv4.

> �The purpose of this working group is to focus on this evolution�.� To what end?

See above.

>  
> The requirements list reads �a solution will cover these technology areas� � I�d be interested in some definition of what promises those technology areas are meant to fulfill, the shape of the solution, not just its composition.

This is where we need folks like yourself and others to contribute. We're still laying out the problem statements and exploring solutions. 

Thanks,

- Mark

>  
> Best,
> Chris
> IPv6 @ Windows
>  
>  
> _______________________________________________
> fun mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/fun

--Apple-Mail-15-946561602
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div><br></div><div><br><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Jul 2, 2011, at 12:52 AM, Christopher Palmer wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div lang="EN-US" link="blue" vlink="purple"><div class="WordSection1" style="page: WordSection1; "><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; ">Hey Folks,<o:p></o:p></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; ">I�ve been trying to keep track of all the feedback concerning the HomeNet Charter. Sorry for bringing up points that may have been discussed before, or are in general noobish.<o:p></o:p></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; ">�End-to-end communication is both an opportunity and a concern as it<o:p></o:p></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; ">enables new applications but also exposes nodes in the internal<o:p></o:p></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; ">networks to receipt of unwanted traffic from the Internet. Firewalls<o:p></o:p></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; ">that restrict incoming connections may be used to prevent exposure,<o:p></o:p></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; ">however, this reduces the efficacy of end-to-end connectivity that<o:p></o:p></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; ">IPv6 has the potential to restore.�<o:p></o:p></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; ">We are absolutely aligned to this objective. IPv6 provides an opportunity to avoid the limiting topology of current IPv4 deployments and this should a priority for everyone in the technology community.<o:p></o:p></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; ">I have points of concern. �Managing routing� is a very broad category of things and I�m not clear about what the vision is there.</div></div></div></span></blockquote><div><br></div><div>Perhaps it is a bad title, &nbsp;but the point that should be clear in the supporting text is that there are existing mechanisms for which each could do a nice job at routing across multiple segments within a v6-enabled homenet, but the pieces need to come together in a way that can be managed by a home user (which we assume will not actively manage anything).</div><br><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div lang="EN-US" link="blue" vlink="purple"><div class="WordSection1" style="page: WordSection1; "><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p></o:p></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; ">The focus on multiple subnet solutions doesn�t seemed align to current operational reality. While I understand the desire to be forward looking, this seems �very� forward looking to a point. I�d be interested in data that reflects the contrary.</div></div></div></span></blockquote><div><br></div><div>Please see:</div><div><br></div><div><a href="http://tools.ietf.org/html/draft-herbst-v6ops-cpeenhancements-00">http://tools.ietf.org/html/draft-herbst-v6ops-cpeenhancements-00</a></div><div><a href="http://tools.ietf.org/html/draft-baker-fun-multi-router-00">http://tools.ietf.org/html/draft-baker-fun-multi-router-00</a></div><div><br></div><br><blockquote type="cite"><div lang="EN-US" link="blue" vlink="purple"><div class="WordSection1" style="page: WordSection1; "><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p></o:p></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; ">Windows and Apple currently use different mechanisms for service discovery. Is unification a goal? WSD is managed by OASIS, which isn�t mentioned for liasoning. Would we imagine the multicast DNS draft moving over to this WG? I�m just confused on what is happening and what is intended to happen. While the charter says routing changes will be handled by the routing area working group, the charter is not that specific on DNS changes.</div></div></div></blockquote><div><br></div><div>There are two aspects here that are clearly in scope:</div><div><br></div><div>One, is figuring out when and how to allow service discovery to reach all services in the home rather than just those on a given link-local-scope. This I believe certainly applies to mDNS, and it might to OASIS. I mentioned in another post that it is certainly much easier when an SDO that the IETF works with has a more open policy, but even when an SDO has a rather closed default policy that arrangements are often possible. This of course requires both willingness on behalf of the partnering SDO, as well as an individual in the IETF who cares enough to make it happen (which I suppose in this case would be you!).&nbsp;</div><div><br></div><div>The other is service discovery itself for home routers. Certainly, a homenet router has its own services to advertise, the most basic of which would be a configuration interface. Traditionally with IPv4, the most basic method for this has been by typing in something like a 192.168.1.1 literal in a web browser. This of course is something that is not possible with IPv6 - not only because IPv6 addresses are difficult for humans to type, but because &nbsp;there is no private space to choose an address from. Also, with more than one router in the home and no possibility of overlapping address space, we need a way to manage more than one router at a time (or at least know which one we are managing).&nbsp;</div><div><br></div><div>I'm not certain we want to get into taking on standardization of service discovery far beyond this in homenet itself, not to say I would not love to see a world where multivendor (including Windows and Apple) service discovery standardized on the same mechanism and worked in a far more consistent manner.</div><div><span class="Apple-style-span" style="font-family: Calibri, sans-serif; font-size: 15px; ">&nbsp;</span></div><blockquote type="cite"><div lang="EN-US" link="blue" vlink="purple"><div class="WordSection1" style="page: WordSection1; "><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; ">I feel like the vision and defining principles could be spelled out more. We want IPv6 home networks to be routable. OK. &nbsp;What else do we want? Why are we doing this?</div></div></div></blockquote><div><br></div><div>The main point is that IPv6 brings issues in home networks that do not fit into the singleton model of single-router, single-link, single-subnet, single-ISP. Those issues in IPv4 will in some cases be overcome with NAT and private addressing, and in some cases will simply not be overcome (at least not at the network level) because the effort to do so in IPv4 is too great. In IPv6, we'd like to not resort to NAT, we'd like to turn on firewall-type security only where it makes sense, etc. - &nbsp;ultimately we'd like the IPv6 homenet to actually work better than the status quo today with IPv4.</div><div><br></div><div><br></div><blockquote type="cite"><div lang="EN-US" link="blue" vlink="purple"><div class="WordSection1" style="page: WordSection1; "><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; ">�The purpose of this working group is to focus on this evolution�.� To what end?</div></div></div></blockquote><div><br></div><div>See above.</div><br><blockquote type="cite"><div lang="EN-US" link="blue" vlink="purple"><div class="WordSection1" style="page: WordSection1; "><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p></o:p></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; ">The requirements list reads �a solution will cover these technology areas� � I�d be interested in some definition of what promises those technology areas are meant to fulfill, the shape of the solution, not just its composition.</div></div></div></blockquote><div><br></div><div>This is where we need folks like yourself and others to contribute. We're still laying out the problem statements and exploring solutions.&nbsp;</div><div><br></div><div>Thanks,</div><div><br></div><div>- Mark</div><br><blockquote type="cite"><div lang="EN-US" link="blue" vlink="purple"><div class="WordSection1" style="page: WordSection1; "><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p></o:p></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; ">Best,<o:p></o:p></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; ">Chris<o:p></o:p></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; ">IPv6 @ Windows<o:p></o:p></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></div></div>_______________________________________________<br>fun mailing list<br><a href="mailto:[email-masked]" style="color: blue; text-decoration: underline; ">[email-masked]</a><br><a href="https://www.ietf.org/mailman/listinfo/fun" style="color: blue; text-decoration: underline; ">https://www.ietf.org/mailman/listinfo/fun</a><br></div></blockquote></div><br></div><br><br></div></div><br></body></html>
--Apple-Mail-15-946561602--

From [email-masked]  Wed Jul  6 09:36:27 2011
Date: Wed, 6 Jul 2011 18:36:22 +0200 (CEST)
From: Mikael Abrahamsson <[email-masked]>
To: Mark Townsley <[email-masked]>
Organization: People's Front Against WWW
Cc: [email-masked], Christopher Palmer <[email-masked]>
Subject: Re: [homenet] Feedback - HomeNet Charter

On Wed, 6 Jul 2011, Mark Townsley wrote:

> Perhaps it is a bad title, but the point that should be clear in the 
> supporting text is that there are existing mechanisms for which each 
> could do a nice job at routing across multiple segments within a 
> v6-enabled homenet, but the pieces need to come together in a way that 
> can be managed by a home user (which we assume will not actively manage 
> anything).

Since I consider multihoming to be in-scope, afaik there is currently no 
way to announce the kind of source-address based forwarding needed when 
one has multiple subnets on a given link, from different ISPs and need to 
choose forwarding to each ISP CPE based on source address of the packet 
seen. I have seen drafts, but I believe there are no current standards for 
doing this.

So I definitely see "producing requirement documents" for these kinds of 
protocols and interacting with other WGs on the matter to be needed.

-- 
Mikael Abrahamsson    email: [email-masked]

From [email-masked]  Fri Jul  8 14:58:37 2011
To: [email-masked]
From: [email-masked]
Date: Fri, 8 Jul 2011 17:57:39 -0400
BBF254DFEB03D08f9e8a93df938690918c0ABBF254DFEB03D0"
Content-Disposition: inline
X-Mailman-Approved-At: Fri, 08 Jul 2011 15:36:30 -0700
Cc: [email-masked], [email-masked]
Subject: [homenet] Home Networks (homenet) WG Chart Feedback
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/homenet>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Fri, 08 Jul 2011 21:58:37 -0000

--0__
BBF254DFEB03D08f9e8a93df938690918c0ABBF254DFEB03D0
Content-type: text/plain; charset=US-ASCII

Resend to [email-masked] mailer list, original sent to

                                                                            

                                                                            
                                                                            
 [email-masked]                                                              

                                                                            

Per
https://www.ietf.org/ibin/c5i?mid=6&ridI&gid=0&k1�4&k2�50&tid10135760
 instructions.

Thanks,

Michael Cowan

Elster Solutions, LLC
Principle Systems Engineer/
HAN Level 2/3 Support
Email:    [email-masked]
Phone:   919-250-5482
Cell:        919-901-9126 (work) or 919-696-4209 (home)
Fax:         919-250-5439

208 South Rogers Lane
Raleigh, NC 27610

This email (and any attachments) is confidential and is intended solely for
the recipient(s) above. Any unauthorized use, disclosure or distribution is
strictly prohibited by law.

__________________

Hello,

   After reading through the Home Networks (homenet) WG Chart, I have the
following feedback, changes highlight in below attachment.

 (See attached file: ITEF HomeNet Working Group chart_MLC_feedback.doc)

Thank You,

Michael Cowan

Elster Solutions, LLC
Principle Systems Engineer/
HAN Level 2/3 Support
Email:    [email-masked]
Phone:   919-250-5482
Cell:        919-901-9126 (work) or 919-696-4209 (home)
Fax:         919-250-5439

208 South Rogers Lane
Raleigh, NC 27610

This email (and any attachments) is confidential and is intended solely for
the recipient(s) above. Any unauthorized use, disclosure or distribution is
strictly prohibited by law.
--0__
BBF254DFEB03D08f9e8a93df938690918c0ABBF254DFEB03D0
Content-type: application/msword; 
	name="ITEF HomeNet Working Group chart_MLC_feedback.doc"
Content-Disposition: attachment; filename="ITEF HomeNet Working Group chart_MLC_feedback.doc"
Content-transfer-encoding: base64

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAASwAAAAAAAAAA
EAAATQAAAAEAAAD+////AAAAAEoAAAD/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////

--0__
BBF254DFEB03D08f9e8a93df938690918c0ABBF254DFEB03D0--

From [email-masked]  Tue Jul 12 07:35:07 2011
From: Mark Townsley <[email-masked]>
Date: Tue, 12 Jul 2011 16:35:03 +0200
To: Fred Baker <[email-masked]>
Cc: [email-masked], ken carlberg <[email-masked]>
Subject: Re: [homenet] [homegate] HOMENET working group proposal

Moving to homenet (from homegate).

Agreeing with Fred, Bufferbloat is certainly bigger than just home networks. If we end up with a nice concentration of home networking expertise in homenet, I'd be happy for that to be a place to help with the problem in terms of review, but at this point I think it should remain outside of the homenet specific deliverables. We've got enough on our plate focusing on the L3-related (and surrounding) topics we have.

- Mark

On Jul 12, 2011, at 4:04 PM, Fred Baker wrote:

> 
> On Jul 12, 2011, at 9:11 AM, ken carlberg wrote:
> 
>> ...I was wondering where something like buffer-bloat, and in particular supporting/managing AQM, would fit in given the above.  Jim Getty's talk at the last IETF meeting was well received and appeared to open some eyes to an issue that seemed to have been easily overseen.  My impression is that work in Home Networks could help address some of the items that Jim brought up in his presentation.
> 
> I think that the need is felt in home, SOHO, and hotel (eg, broadband last mile) networks, and suggestions I have made along such lines have focused on them. However, the topic is closer to the charter of tsvwg IMHO, except in the ways that it manifests in broadband interfaces (the fact of the router, modem, CMTS/DSLAM, and upstream router being separate entities with separate buffers). The problem is in essence that ECN/AQM is generally not implemented in such networks, in part because there is a sense on the carrier side that loss is a bad thing, and in part because tuning the algorithms can be a pain. What the Georgia Tech folks have worked out, as much as anything, is an acceptable configuration driven by user perceptions rather than research optimizations (eg, for them it's not about finding the absolute knee of the curve and making the combined queue be as thin as possible, but finding a pragmatic solution that is predictable and acceptable to the typical user).

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

From [email-masked]  Tue Jul 12 11:16:55 2011
Date: Tue, 12 Jul 2011 23:46:43 +0530
From: Jari Arkko <[email-masked]>
To: Fred Baker <[email-masked]>
Cc: [email-masked], ken carlberg <[email-masked]>
Subject: Re: [homenet] [homegate] HOMENET working group proposal

Fred ,

>> ...I was wondering where something like buffer-bloat, and in particular supporting/managing AQM, would fit in given the above.  Jim Getty's talk at the last IETF meeting was well received and appeared to open some eyes to an issue that seemed to have been easily overseen.  My impression is that work in Home Networks could help address some of the items that Jim brought up in his presentation.
>>     
>
> I think that the need is felt in home, SOHO, and hotel (eg, broadband last mile) networks, and suggestions I have made along such lines have focused on them. However, the topic is closer to the charter of tsvwg IMHO,

I agree

jari

From [email-masked]  Thu Jul 14 09:41:22 2011
From: Mark Townsley <[email-masked]>
Date: Thu, 14 Jul 2011 18:41:08 +0200
To: Ralph Droms <[email-masked]>
Cc: [email-masked], [email-masked], The IESG <[email-masked]>
Subject: Re: [homenet] [homegate] homegate Working Group charter approved

s/homegate/homenet

Ralph is in an airport between flights, and clearly something with the altitude, fumes, or drinks served caused him to slip back in time here.

- Mark

PS. The order is already in to disable the homegate list. It's [email-masked] for everything from here on.

On Jul 14, 2011, at 6:36 PM, Ralph Droms wrote:

> The IESG approved the formation of the homegate Working Group during today's telechat.  The WG's first meeting will be in Quebec, as shown in the IETF-81 meeting agenda.  The initial charter for the WG is included below.  Mark Townsley has agreed to be one of the WG co-chairs (thanks, Mark!).  We will be choosing a second co-chair soon, so please let Jari and me know if you're interested in taking on that role.
> 
> Mark will start a thread here soon to develop the agenda for the upcoming WG meeting.
> 
> Thanks to all of you who have been following the development of the WG and especially for the enthusiastic discussion about the charter.  We're counting on all of you to continue your contributions to the success of the WG.
> 
> - Ralph Droms
>  Internet Area Director
> 
> Home Networks (homenet)
> -----------------------------------
> 
> Current Status: Proposed
> Last Edit: Wednesday, July 14th, 2011
> 
> Chairs:
> "W. Mark Townsley" <[email-masked]>
> 
> Internet Area Directors:
> Ralph Droms <[email-masked]>
> Jari Arkko <[email-masked]>
> 
> Internet Area Advisor:
> Ralph Droms <[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 for the home. 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, as appropriate. 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 group should assume that an IPv4 network may have
> to co-exist alongside the IPv6 network and should take this into
> account insofar as alignment with IPv6 is desirable. But the group
> should also ensure that even IPv6-only are possible, and while
> IP-version agnostic work is of course desirable, IPv4-specific work is
> outside the scope of the group.
> 
> 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 liason 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, 
> as is understanding existing technology from these groups.
> 
> 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
> _______________________________________________
> homegate mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homegate

From [email-masked]  Thu Jul 14 09:41:39 2011
From: Ralph Droms <[email-masked]>
Date: Thu, 14 Jul 2011 12:41:32 -0400
To: [email-masked]
Cc: Mark Townsley <[email-masked]>, The IESG <[email-masked]>
Subject: [homenet] homenet Working Group charter approved

The IESG approved the formation of the homenet Working Group during today's telechat.  The WG's first meeting will be in Quebec, as shown in the IETF-81 meeting agenda.  The initial charter for the WG is included below.  Mark Townsley has agreed to be one of the WG co-chairs (thanks, Mark!).  We will be choosing a second co-chair soon, so please let Jari and me know if you're interested in taking on that role.

Mark will start a thread here soon to develop the agenda for the upcoming WG meeting.

Thanks to all of you who have been following the development of the WG and especially for the enthusiastic discussion about the charter.  We're counting on all of you to continue your contributions to the success of the WG.

- Ralph Droms
 Internet Area Director

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

Current Status: Proposed
Last Edit: Wednesday, July 14th, 2011

Chairs:
"W. Mark Townsley" <[email-masked]>

Internet Area Directors:
Ralph Droms <[email-masked]>
Jari Arkko <[email-masked]>

Internet Area Advisor:
Ralph Droms <[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 for the home. 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, as appropriate. 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 group should assume that an IPv4 network may have
to co-exist alongside the IPv6 network and should take this into
account insofar as alignment with IPv6 is desirable. But the group
should also ensure that even IPv6-only are possible, and while
IP-version agnostic work is of course desirable, IPv4-specific work is
outside the scope of the group.

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 liason 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, 
as is understanding existing technology from these groups.

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 [email-masked]  Thu Jul 14 09:56:34 2011
From: Paul Hoffman <[email-masked]>
Date: Thu, 14 Jul 2011 09:56:29 -0700
To: Ralph Droms <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [homenet] homenet Working Group charter approved

Given that the approved charter has the WG list as "[email-masked]" instead of "[email-masked]", could you either:
- shut down [email-masked]
- revise the charter to point to [email-masked] and shut down [email-masked]
This is *surely* going to cause even more problems than we have seen in the past few weeks.

--Paul Hoffman
From [email-masked]  Thu Jul 14 10:00:25 2011
From: Ralph Droms <[email-masked]>
Date: Thu, 14 Jul 2011 13:00:18 -0400
To: Paul Hoffman <[email-masked]>
Cc: [email-masked], Jari Arkko <[email-masked]>, Ralph Droms <[email-masked]>, [email-masked]
Subject: Re: [homenet] homenet Working Group charter approved

Good catch and I've requested that the charter be revised to point at "[email-masked]" before final publication.

I think "[email-masked]" is already gone; I will confirm.

- Ralph

On Jul 14, 2011, at 12:56 PM 7/14/11, Paul Hoffman wrote:

> Given that the approved charter has the WG list as "[email-masked]" instead of "[email-masked]", could you either:
> - shut down [email-masked]
> - revise the charter to point to [email-masked] and shut down [email-masked]
> This is *surely* going to cause even more problems than we have seen in the past few weeks.
> 
> --Paul Hoffman

From [email-masked]  Thu Jul 14 10:02:00 2011
From: Ralph Droms <[email-masked]>
Date: Thu, 14 Jul 2011 13:01:51 -0400
To: Paul Hoffman <[email-masked]>
Cc: [email-masked], Jari Arkko <[email-masked]>, [email-masked]
Subject: Re: [homenet] homenet Working Group charter approved

I was wrong, "[email-masked]" still exists.  I will ask for it to be shut down, preserving the archive.

- Ralph

On Jul 14, 2011, at 1:00 PM 7/14/11, Ralph Droms wrote:

> Good catch and I've requested that the charter be revised to point at "[email-masked]" before final publication.
> 
> I think "[email-masked]" is already gone; I will confirm.
> 
> - Ralph
> 
> On Jul 14, 2011, at 12:56 PM 7/14/11, Paul Hoffman wrote:
> 
>> Given that the approved charter has the WG list as "[email-masked]" instead of "[email-masked]", could you either:
>> - shut down [email-masked]
>> - revise the charter to point to [email-masked] and shut down [email-masked]
>> This is *surely* going to cause even more problems than we have seen in the past few weeks.
>> 
>> --Paul Hoffman
> 
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

From [email-masked]  Thu Jul 14 13:08:00 2011
From: Mark Townsley <[email-masked]>
Date: Thu, 14 Jul 2011 22:07:52 +0200
To: "STARK, BARBARA H (ATTSI)" <[email-masked]>
Cc: [email-masked], Ralph Droms <[email-masked]>, [email-masked]
Subject: Re: [homenet] homenet Working Group charter approved

--Apple-Mail-40--493093178
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii

We'll ask to have people migrated, but you never know... 

To be sure, please sign up here to join in on the fun right away:

https://www.ietf.org/mailman/listinfo/homenet

- Mark

On Jul 14, 2011, at 8:18 PM, STARK, BARBARA H (ATTSI) wrote:

> Can you confirm whether the homegate list will be automatically
> transition to homenet, or do we need to individually sign up for
> homenet?
> Barbara
> 
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of Mark Townsley
>> Sent: Thursday, July 14, 2011 12:41 PM
>> To: Ralph Droms
>> Cc: [email-masked]; [email-masked]; The IESG
>> Subject: Re: [homegate] homegate Working Group charter approved
>> 
>> 
>> s/homegate/homenet
>> 
>> Ralph is in an airport between flights, and clearly something with the
>> altitude, fumes, or drinks served caused him to slip back in time
> here.
>> 
>> - Mark
>> 
>> PS. The order is already in to disable the homegate list. It's
>> [email-masked] for everything from here on.
>> 
>> On Jul 14, 2011, at 6:36 PM, Ralph Droms wrote:
>> 
>>> The IESG approved the formation of the homegate Working Group during
>> today's telechat.  The WG's first meeting will be in Quebec, as shown
>> in the IETF-81 meeting agenda.  The initial charter for the WG is
>> included below.  Mark Townsley has agreed to be one of the WG
> co-chairs
>> (thanks, Mark!).  We will be choosing a second co-chair soon, so
> please
>> let Jari and me know if you're interested in taking on that role.
>>> 
>>> Mark will start a thread here soon to develop the agenda for the
>> upcoming WG meeting.
>>> 
>>> Thanks to all of you who have been following the development of the
>> WG and especially for the enthusiastic discussion about the charter.
>> We're counting on all of you to continue your contributions to the
>> success of the WG.
>>> 
>>> - Ralph Droms
>>> Internet Area Director
>>> 
>>> Home Networks (homenet)
>>> -----------------------------------
>>> 
>>> Current Status: Proposed
>>> Last Edit: Wednesday, July 14th, 2011
>>> 
>>> Chairs:
>>> "W. Mark Townsley" <[email-masked]>
>>> 
>>> Internet Area Directors:
>>> Ralph Droms <[email-masked]>
>>> Jari Arkko <[email-masked]>
>>> 
>>> Internet Area Advisor:
>>> Ralph Droms <[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 for the home. 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, as appropriate. 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 group should assume that an IPv4 network may
> have
>>> to co-exist alongside the IPv6 network and should take this into
>>> account insofar as alignment with IPv6 is desirable. But the group
>>> should also ensure that even IPv6-only are possible, and while
>>> IP-version agnostic work is of course desirable, IPv4-specific work
>> is
>>> outside the scope of the group.
>>> 
>>> 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 liason 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,
>>> as is understanding existing technology from these groups.
>>> 
>>> 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
>>> _______________________________________________
>>> homegate mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/homegate
>> 
>> _______________________________________________
>> homegate mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/homegate

--Apple-Mail-40--493093178
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div>We'll ask to have people migrated, but you never know...&nbsp;</div><div><br></div><div>To be sure, please sign up here to join in on the fun right away:</div><div><br></div><div><a href="https://www.ietf.org/mailman/listinfo/homenet">https://www.ietf.org/mailman/listinfo/homenet</a></div><div><br></div><div>- Mark</div><div><br></div><br><div><div>On Jul 14, 2011, at 8:18 PM, STARK, BARBARA H (ATTSI) wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Can you confirm whether the homegate list will be automatically<br>transition to homenet, or do we need to individually sign up for<br>homenet?<br>Barbara<br><br><blockquote type="cite">-----Original Message-----<br></blockquote><blockquote type="cite">From: <a href="mailto:[email-masked]">[email-masked]</a> [mailto:[email-masked]] On<br></blockquote><blockquote type="cite">Behalf Of Mark Townsley<br></blockquote><blockquote type="cite">Sent: Thursday, July 14, 2011 12:41 PM<br></blockquote><blockquote type="cite">To: Ralph Droms<br></blockquote><blockquote type="cite">Cc: <a href="mailto:[email-masked]">[email-masked]</a>; <a href="mailto:[email-masked]">[email-masked]</a>; The IESG<br></blockquote><blockquote type="cite">Subject: Re: [homegate] homegate Working Group charter approved<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">s/homegate/homenet<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Ralph is in an airport between flights, and clearly something with the<br></blockquote><blockquote type="cite">altitude, fumes, or drinks served caused him to slip back in time<br></blockquote>here.<br><blockquote type="cite"><br></blockquote><blockquote type="cite">- Mark<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">PS. The order is already in to disable the homegate list. It's<br></blockquote><blockquote type="cite"><a href="mailto:[email-masked]">[email-masked]</a> for everything from here on.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">On Jul 14, 2011, at 6:36 PM, Ralph Droms wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">The IESG approved the formation of the homegate Working Group during<br></blockquote></blockquote><blockquote type="cite">today's telechat. &nbsp;The WG's first meeting will be in Quebec, as shown<br></blockquote><blockquote type="cite">in the IETF-81 meeting agenda. &nbsp;The initial charter for the WG is<br></blockquote><blockquote type="cite">included below. &nbsp;Mark Townsley has agreed to be one of the WG<br></blockquote>co-chairs<br><blockquote type="cite">(thanks, Mark!). &nbsp;We will be choosing a second co-chair soon, so<br></blockquote>please<br><blockquote type="cite">let Jari and me know if you're interested in taking on that role.<br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Mark will start a thread here soon to develop the agenda for the<br></blockquote></blockquote><blockquote type="cite">upcoming WG meeting.<br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Thanks to all of you who have been following the development of the<br></blockquote></blockquote><blockquote type="cite">WG and especially for the enthusiastic discussion about the charter.<br></blockquote><blockquote type="cite">We're counting on all of you to continue your contributions to the<br></blockquote><blockquote type="cite">success of the WG.<br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">- Ralph Droms<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> Internet Area Director<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Home Networks (homenet)<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">-----------------------------------<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Current Status: Proposed<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Last Edit: Wednesday, July 14th, 2011<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Chairs:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">"W. Mark Townsley" &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Internet Area Directors:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Ralph Droms &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Jari Arkko &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Internet Area Advisor:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Ralph Droms &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Routing Area Technical Advisor:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">TBD<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Security Area Technical Advisor:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">TBD<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Mailing Lists:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">General Discussion: <a href="mailto:[email-masked]">[email-masked]</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">To Subscribe: <a href="https://www.ietf.org/mailman/listinfo/fun">https://www.ietf.org/mailman/listinfo/fun</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Archive: <a href="http://www.ietf.org/mail-archive/web/fun">http://www.ietf.org/mail-archive/web/fun</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Description of Working Group:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">This working group focuses on the evolving networking technology<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">within and among relatively small "residential home" networks. For<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">example, an obvious trend in home networking is the proliferation of<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">networking technology in an increasingly broad range and number of<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">devices. This evolution in scale and diversity sets some<br></blockquote></blockquote>requirements<br><blockquote type="cite"><blockquote type="cite">on IETF protocols. Some of the relevant trends include:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">o &nbsp;Multiple segments: While less complex L3-toplogies involving as<br></blockquote></blockquote><blockquote type="cite">few<br></blockquote><blockquote type="cite"><blockquote type="cite"> subnets as possible are preferred in home networks for a variety of<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> reasons including simpler management and service discovery, the<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> introduction of more than one subnet into a home network is enough<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> to add complexity that needs to be addressed, and multiple<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> dedicated segments are necessary for some cases. &nbsp;For instance, a<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> common feature in modern home routers in the ability to support<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> both guest and private network segments. Also, link layer<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> networking technology is poised to become more heterogeneous, as<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> networks begin to employ both traditional Ethernet technology and<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> link layers designed for low-powered sensor networks. Finally,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> similar needs for segmentation may occur in other cases, such as<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> separating building control or corporate extensions from the<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> Internet access network for the home. Different segments may be<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> associated with subnets that have different routing and security<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> policies.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">o &nbsp;Service providers are deploying IPv6, and support for IPv6 is<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> increasingly available in home gateway devices. While IPv6<br></blockquote></blockquote>resembles<br><blockquote type="cite"><blockquote type="cite"> IPv4 in many ways, it changes address allocation principles and<br></blockquote></blockquote><blockquote type="cite">allows<br></blockquote><blockquote type="cite"><blockquote type="cite"> direct IP addressability and routing to devices in the home from<br></blockquote></blockquote>the<br><blockquote type="cite"><blockquote type="cite"> Internet. This is a promising area in IPv6 that has proved<br></blockquote></blockquote><blockquote type="cite">challenging<br></blockquote><blockquote type="cite"><blockquote type="cite"> in IPv4 with the proliferation of NAT.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">o &nbsp;End-to-end communication is both an opportunity and a concern as<br></blockquote></blockquote><blockquote type="cite">it<br></blockquote><blockquote type="cite"><blockquote type="cite"> enables new applications but also exposes nodes in the internal<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> networks to receipt of unwanted traffic from the Internet.<br></blockquote></blockquote>Firewalls<br><blockquote type="cite"><blockquote type="cite"> that restrict incoming connections may be used to prevent exposure,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> however, this reduces the efficacy of end-to-end connectivity that<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> IPv6 has the potential to restore.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Home networks need to provide the tools to handle these situations<br></blockquote></blockquote>in<br><blockquote type="cite"><blockquote type="cite">a manner accessible to all users of home networks. Manual<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">configuration is rarely, if at all, possible, as the necessary<br></blockquote></blockquote>skills<br><blockquote type="cite"><blockquote type="cite">and in some cases even suitable management interfaces are missing.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">The purpose of this working group is to focus on this evolution, in<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">particular as it addresses the introduction of IPv6, by developing<br></blockquote></blockquote>an<br><blockquote type="cite"><blockquote type="cite">architecture addressing this full scope of requirements:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">o &nbsp;prefix configuration for routers<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">o &nbsp;managing routing<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">o &nbsp;name resolution<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">o &nbsp;service discovery<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">o &nbsp;network security<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">The task of the group is to produce an architecture document that<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">outlines how to construct home networks involving multiple routers<br></blockquote></blockquote><blockquote type="cite">and<br></blockquote><blockquote type="cite"><blockquote type="cite">subnets. This document is expected to apply the IPv6 addressing<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">architecture, prefix delegation, global and ULA addresses, source<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">address selection rules and other existing components of the IPv6<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">architecture, as appropriate. The architecture document should drive<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">what protocols changes, if any, are necessary. Specific protocol<br></blockquote></blockquote>work<br><blockquote type="cite"><blockquote type="cite">described below is expected to be within the scope of the working<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">group once the architecture work is complete. However, the group is<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">required to review its charter and milestones with the IESG and IETF<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">community before submitting documents that make protocol changes. It<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">is expected that the group has to discuss some of the below<br></blockquote></blockquote><blockquote type="cite">solutions,<br></blockquote><blockquote type="cite"><blockquote type="cite">however, in order to complete the architecture work.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">The group will apply existing protocols to handle the five<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">requirements above. For prefix configuration, existing protocols are<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">likely sufficient, and at worst may need some small enhancements,<br></blockquote></blockquote><blockquote type="cite">such<br></blockquote><blockquote type="cite"><blockquote type="cite">as new options. For automatic routing, it is expected that existing<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">routing protocols can be used as is, however, a new mechanism may be<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">needed in order to turn a selected protocol on by default. For name<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">resolution and service discovery, extensions to existing<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">multicast-based name resolution protocols are needed to enable them<br></blockquote></blockquote><blockquote type="cite">to<br></blockquote><blockquote type="cite"><blockquote type="cite">work across subnets.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">For network security, the group shall document the concept of<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">"advanced security" as a further development of "simple security"<br></blockquote></blockquote><blockquote type="cite">from<br></blockquote><blockquote type="cite"><blockquote type="cite">RFC 6092. The main goal of this work is to enable a security policy<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">that adapts to IPv6 threats as they emerge, taking into account not<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">only traffic from the Internet at large, but within and leaving the<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">home network itself.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">It is expected that the working group will define a set of protocol<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">specifications to accomplish the five requirements from<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">above. However, it is not in the scope of the working group to<br></blockquote></blockquote>define<br><blockquote type="cite"><blockquote type="cite">entirely new routing protocols or address allocation protocols. As<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">noted, additional options or other small extensions may be necessary<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">to use the existing protocols in these new configuration tasks. The<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">working group shall also not make any changes to IPv6 protocols or<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">addressing architecture. Prefix configuration, routing, and security<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">related work shall not cause any changes that are not backwards<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">compatible to existing IPv6 hosts. There may be host visible changes<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">in the work on naming and discovery protocols, however. In its<br></blockquote></blockquote><blockquote type="cite">design,<br></blockquote><blockquote type="cite"><blockquote type="cite">the working group shall also consider security aspects and the<br></blockquote></blockquote>impact<br><blockquote type="cite"><blockquote type="cite">on manageability. The main focus of the working group is home<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">networks, but the group's results may also find applications in<br></blockquote></blockquote>other<br><blockquote type="cite"><blockquote type="cite">small networks. The group should assume that an IPv4 network may<br></blockquote></blockquote>have<br><blockquote type="cite"><blockquote type="cite">to co-exist alongside the IPv6 network and should take this into<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">account insofar as alignment with IPv6 is desirable. But the group<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">should also ensure that even IPv6-only are possible, and while<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">IP-version agnostic work is of course desirable, IPv4-specific work<br></blockquote></blockquote><blockquote type="cite">is<br></blockquote><blockquote type="cite"><blockquote type="cite">outside the scope of the group.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">The working group will liaise with the relevant IETF working<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">groups. In particular, the group should work closely with the V6OPS<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">working group, review any use or extension of DHCP with the DHC<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">working group, and work with additional DNS requirements with the<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">DNSEXT and DNSOP working groups. If it turns out that additional<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">options are needed for a routing protocol, they will be developed in<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">the appropriate Routing Area working group, with the HOMENET working<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">group providing the architecture and requirements for such<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">enhancements. The working group will also liason with external<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">standards bodies where it is expected that there are normative<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">dependencies between the specifications of the two bodies.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">It is expected that in the architecture definition stage liaising<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">with the Broadband Forum, DLNA, and UPnP Forum is necessary,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">as is understanding existing technology from these groups.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Milestones:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Jul 2011 Formation of the working group<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Sep 2011 First WG draft on the architecture<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Dec 2011 Submission of the architecture draft to the IESG as<br></blockquote></blockquote><blockquote type="cite">Informational RFC<br></blockquote><blockquote type="cite"><blockquote type="cite">Dec 2011 Charter re-evaluation based on the architecture work<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Dec 2011 First WG draft on prefix configuration<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Dec 2011 First WG draft on routing<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Jan 2012 First WG draft on name resolution<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Feb 2012 First WG draft on service discovery<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Feb 2012 First WG draft on perimeter security<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Feb 2012 Start of routing related work in the relevant routing area<br></blockquote></blockquote><blockquote type="cite">working group, if needed<br></blockquote><blockquote type="cite"><blockquote type="cite">Mar 2012 Submission of the prefix configuration draft to the IESG as<br></blockquote></blockquote><blockquote type="cite">Standards Track RFC<br></blockquote><blockquote type="cite"><blockquote type="cite">Apr 2012 Submission of the routing draft to the IESG as<br></blockquote></blockquote>Informational<br><blockquote type="cite">RFC<br></blockquote><blockquote type="cite"><blockquote type="cite">Sep 2012 Submission of the name resolution draft to the IESG as<br></blockquote></blockquote><blockquote type="cite">Standards Track RFC<br></blockquote><blockquote type="cite"><blockquote type="cite">Nov 2012 Submission of the service discovery draft to the IESG as<br></blockquote></blockquote><blockquote type="cite">Standards Track RFC<br></blockquote><blockquote type="cite"><blockquote type="cite">Dec 2012 Submission of the perimeter security draft to the IESG as<br></blockquote></blockquote><blockquote type="cite">Informational RFC<br></blockquote><blockquote type="cite"><blockquote type="cite">_______________________________________________<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">homegate mailing list<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><a href="mailto:[email-masked]">[email-masked]</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><a href="https://www.ietf.org/mailman/listinfo/homegate">https://www.ietf.org/mailman/listinfo/homegate</a><br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite">homegate mailing list<br></blockquote><blockquote type="cite"><a href="mailto:[email-masked]">[email-masked]</a><br></blockquote><blockquote type="cite"><a href="https://www.ietf.org/mailman/listinfo/homegate">https://www.ietf.org/mailman/listinfo/homegate</a><br></blockquote></div></blockquote></div><br></body></html>
--Apple-Mail-40--493093178--

From [email-masked]  Fri Jul 15 11:25:49 2011
From: Mark Townsley <[email-masked]>
Date: Fri, 15 Jul 2011 20:25:39 +0200
To: [email-masked]
Subject: [homenet] Getting ready for Quebec

Welcome to Homenet everyone. 

We currently have a meeting slot on Wednesday at 1300, for two hours. This meeting will likely have a "Bofish" feel to it, since it is our first in-person meeting under the homenet charter. 

I'd like to outline one possible agenda for making the best use of our timeslot. I'll also be asking for volunteers in here, as we have a lot of positions to fill in our new group. First is for co-chair, Ralph and Jari already made a call to the list for that (and received several responses as I understand). 

I'd also like to go ahead and ask for a note-taking volunteer and jabber scribe. If you are really good at taking notes and enjoy it, I'll ask Ralph to deem you as WG Secretary with full titles and privileges therein, then you can do it again and again! :-)

Initial shot at an agenda, comments welcome, volunteers appreciated even if I put a couple of names down already.

1300-1310 (10 min) Agenda Bashing and Administrivia

1300-1350 (50 min)

Jari and I will start out discussing the charter and the (very drafty) initial homenet architecture document. While we co-authored this first document, our goal is to hand this off quickly to a willing and capable volunteer. Please send me email if you would like to volunteer for that role.

Background Reading:
Homenet Charter
draft-arkko-townsley-homenet-arch-00 (drafty draft)

Let's consider RFC 6204 and draft-ietf-v6ops-ipv6-cpe-router-bis-01 as background reading for this discussion as well. I'm hoping the ADs, draft authors, and v6ops chairs can give us guidance on what should happen with this latter document as well (does it stay in v6ops, or move to homenet?).

I'd like to then focus on some of the specifics in our 5 concentration areas. We may not have time for all 5 this time, but in general I'd like to structure our WG meetings around driving forward within each of these areas and track progress for each. 

1350-1430 (30 min) - Fred Baker?

   o  prefix configuration for routers
   o  managing routing

Background Reading:
http://tools.ietf.org/html/draft-baker-fun-multi-router-00
http://tools.ietf.org/html/draft-baker-fun-routing-class-00
http://tools.ietf.org/html/draft-herbst-v6ops-cpeenhancements-00

1430 - 1430 (0 min, unless a draft and volunteer appear before Quebec)

   o  name resolution
   o  service discovery

I haven't seen specific contributions on name resolution or service discovery as of yet. I would very much like to see a document and presentation describing the differences between, say, OASIS, UPnP (DLNA?), and Bonjour (mDNS, DNS-SD, LLMNR, etc.) alternatives simply so that the WG can understand the various overlaps and commonalities, and where IPv6 fits in (without having to be members of each of these groups, as has been brought up on the list before). Challenges around naming in general, etc. If we don't have this before Quebec, I understand. But I would at least like to have a volunteer to put a name next to. 

1430-1450 (20 min) - Eric Vyncke?

   o  network security

Background Reading:
RFC 6092 and draft-vyncke-advanced-ipv6-security-01 

1450 - 1500 - Chair(s)/AD(s) 

Conclusions, AIs, Next Steps....

Thanks and see you in Quebec!!

- Mark

From [email-masked]  Sun Jul 17 13:01:17 2011
Date: Sun, 17 Jul 2011 22:01:07 +0200
From: Wouter Cloetens <[email-masked]>
To: [email-masked]
Subject: [homenet] Idea regarding IPv6 RDNS on residential gateways

Greetings,

As you know, reverse name lookups are an issue on IPv6. I have an idea 
on how to resolve that, and I'm working on an Internet draft:
  http://e2big.org/ietf/draft-cloetens-homenet-dns-delegation

It's not quite ready, but I'm posting to this list so it can be 
discussed in Quebec. My workload does not permit me to attend the 
meeting in person.

In a nutshell:
Gateways can discover host names of hosts behind them in various ways. 
mDNS, UPnP SSDP discovery, DHCPv4 names, manual configuration via the 
web UI are among the methods the gateway product of which I am the 
architect uses. While some of these only work on IPv4, it is so that 
most devices will be dual stack for a while, and the gateway can 
perfectly correlate the IPv4 and IPv6 addresses based on the MAC address 
of the host. Whatever mechanism is used should be left to the GW 
implementer; it should be out of the scope of the specification.

Gateways typically have a DNS relay in them as well. Our own product 
serves the discovered IPv4 hostnames vs. the private range addresses in 
the ".home" domain. The point is that they're capable of handling DNS 
requests.

So, if the ISP's DNS infrastructure would delegate host name lookups 
recursively to the gateways, the problem is solved.
What you'd need, to begin with, is a domain name corresponding to the 
delegated prefix. Say your ISP is "example.com." A user could register 
"foo". The ISP can then delegate forward lookups for "foo.example.com" 
to your GW when it is connected. Reverse address lookups are delegated 
to your GW for the delegated prefix (or prefixes) and for the GW's 
public address, which it received via DHCPv6 or SLAAC.
Note that a user really needs to register that subdomain "foo." Dynamic 
registration doesn't work because someone could then hijack your domain. 
I'm sure ISP's will see a business model in selling you domains without 
their own domain name in it too. To ensure that reverse address lookups 
always work, the ISP could come up with default subdomain per customer, 
and allow the customer to change it if he wants and if the ISP allows it.

At the time of WAN prefix delegation, the gateway could set an option in 
the DHCPv6 request to indicate that it is capable of DNS delegation. The 
DHCPv6 reply options could indicate acknowledgement and what your domain 
name is (possibly multiple names). For security reasons, I'd add a list 
of prefixes of the ISP's upstream DNS servers, so the GW can restrict 
legal sources of DNS requests. A user should be able to manually extend 
that list, so he can register his own domain and configure rDNS for it.

The beauty of that design is that downstream GW's on the LAN side of the 
GW can be handled too. Just configure another subdomain for it on the 
primary GW and the rest is managed through DHCPv6 PD. Of course, the 
GW's DNS needs to be able to delegate requests itself.
DNS names for ULA's or site-local prefixes could be handled too between 
these gateways.

There are additional security and implementation concerns, e.g. DNS 
record TTL correlation with lease duration, but this is the gist of it.

I'm still tackling the final issue of how to communicate the globally 
routable IPv6 address from the gateway to the DHCP server in a way that 
allows the DHCP server to verify the address. Some interaction between 
next-hop upstream router, DHCP relay and DHCP server may be required.
My professional problem space ends at the connection between residential 
gateway and ISP access network, so I am stepping outside the boundaries 
of my domain expertise here. Some guidance would be much appreciated.

bfn, Wouter
-- 
Architect Core Gateway   SoftAtHome R&D RGW  http://www.softathome.com/

From [email-masked]  Tue Jul 19 01:22:37 2011
From: Ray Bellis <[email-masked]>
To: Wouter Cloetens <[email-masked]>
Date: Tue, 19 Jul 2011 08:22:28 +0000
Accept-Language: en-GB, en-US
Cc: "<[email-masked]>" <[email-masked]>
Subject: Re: [homenet] Idea regarding IPv6 RDNS on residential gateways

On 17 Jul 2011, at 21:01, Wouter Cloetens wrote:

> Gateways typically have a DNS relay in them as well. Our own product serves the discovered IPv4 hostnames vs. the private range addresses in the ".home" domain. The point is that they're capable of handling DNS requests.
> 
> So, if the ISP's DNS infrastructure would delegate host name lookups recursively to the gateways, the problem is solved.

Oh god, please no!

Most vendors can't even make the outbound relay work right.  See RFC 5625.

Several vendors also leave the outbound relays inadvertently open on the WAN side too, allowing those units to be used as open relays for hiding traffic and/or creating amplification attacks.  IMHO, having the CPE intentionally prepared to answer questions from the WAN side is likely to cause even more breakage due to poor implementations.

kind regards,

Ray
 
From [email-masked]  Tue Jul 19 05:10:23 2011
From: Arturo Servin <[email-masked]>
Date: Tue, 19 Jul 2011 09:09:49 -0300
To: Ray Bellis <[email-masked]>
X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information
X-LACNIC.uy-MailScanner: Found to be clean
X-LACNIC.uy-MailScanner-SpamCheck: 
X-LACNIC.uy-MailScanner-From: [email-masked]
Cc: "<[email-masked]>" <[email-masked]>, Wouter Cloetens <[email-masked]>
Subject: Re: [homenet] Idea regarding IPv6 RDNS on residential gateways
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/homenet>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Tue, 19 Jul 2011 12:10:23 -0000

	Wouldn't this create LAME delegations when the CPE is off?

.as

On 19 Jul 2011, at 05:22, Ray Bellis wrote:

> 
> On 17 Jul 2011, at 21:01, Wouter Cloetens wrote:
> 
>> Gateways typically have a DNS relay in them as well. Our own product serves the discovered IPv4 hostnames vs. the private range addresses in the ".home" domain. The point is that they're capable of handling DNS requests.
>> 
>> So, if the ISP's DNS infrastructure would delegate host name lookups recursively to the gateways, the problem is solved.
> 
> Oh god, please no!
> 
> Most vendors can't even make the outbound relay work right.  See RFC 5625.
> 
> Several vendors also leave the outbound relays inadvertently open on the WAN side too, allowing those units to be used as open relays for hiding traffic and/or creating amplification attacks.  IMHO, having the CPE intentionally prepared to answer questions from the WAN side is likely to cause even more breakage due to poor implementations.
> 
> kind regards,
> 
> Ray
> 
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

From [email-masked]  Tue Jul 19 05:11:12 2011
Date: Tue, 19 Jul 2011 14:10:58 +0200
From: Wouter Cloetens <[email-masked]>
To: Ray Bellis <[email-masked]>,  "<[email-masked]>" <[email-masked]>
Subject: Re: [homenet] Idea regarding IPv6 RDNS on residential gateways

On 19/07/11 10:22, Ray Bellis wrote:
>
> On 17 Jul 2011, at 21:01, Wouter Cloetens wrote:
>
>> Gateways typically have a DNS relay in them as well. Our own
>> product serves the discovered IPv4 hostnames vs. the private range
>> addresses in the ".home" domain. The point is that they're capable
>> of handling DNS requests.
>>
>> So, if the ISP's DNS infrastructure would delegate host name
>> lookups recursively to the gateways, the problem is solved.
>
> Oh god, please no!
 >
 > Most vendors can't even make the outbound relay work right.  See RFC
 > 5625.

RFC's, the IETF, and leading equipment vendors have the responsibility 
and the task to implement correctly and educate, so the implementations 
are done right. ;-)
Or do you think we shouldn't bother because people will implement it 
wrong any way? I think we should publish clear, thoroughly thought 
through, closed specs, _before_ anyone starts implementing this in their 
own goofy way. Not publish a "you shouldn't do that" RFC afterwards. So: 
"oh god, please yes, now!"

> Several vendors also leave the outbound relays inadvertently open on
> the WAN side too, allowing those units to be used as open relays for
> hiding traffic and/or creating amplification attacks.  IMHO, having
> the CPE intentionally prepared to answer questions from the WAN side
> is likely to cause even more breakage due to poor implementations.

I'm personally responsible for fixing that hole in a broken 
implementation from another vendor. I'm well aware of the risks.

Hence the security section, and the two layers of defence. Even if there 
is a CPE out there with an exploitable security hole, restrict the 
source addresses of the DNS requests to the DNS relays of the ISP.

bfn, Wouter
-- 
Architect Core Gateway   SoftAtHome R&D RGW  http://www.softathome.com/

From [email-masked]  Tue Jul 19 05:16:16 2011
Date: Tue, 19 Jul 2011 14:16:03 +0200
From: Wouter Cloetens <[email-masked]>
To: Arturo Servin <[email-masked]>,  "<[email-masked]>" <[email-masked]>
Subject: Re: [homenet] Idea regarding IPv6 RDNS on residential gateways

On 19/07/11 14:09, Arturo Servin wrote:
> 	Wouldn't this create LAME delegations when the CPE is off?

Caching will catch a fraction of that, but yes, that can't be avoided in 
my proposal.
Is that a problem? It will just result in a time-out.

Would it be more desirable for the network to detect that the CPE is no 
longer present, and automatically reconfigure the domain to 
authoritatively responding "not found" instead of delegating?

bfn, Wouter
-- 
Architect Core Gateway   SoftAtHome R&D RGW  http://www.softathome.com/
http://www.linkedin.com/in/wcloetens  Vaartdijk 3/B701, B-3018 Wijgmaal
Tel: +32-16-852010      Mobile: +32-492-277790       Fax: +32-16-852099

This message and any attachments are confidential, intended solely for
the addressees and are SoftAtHome�s ownership.
Any unauthorized use or dissemination is prohibited. If you are not the
intended addressee of this message, please cancel it immediately and
inform the sender.

From [email-masked]  Tue Jul 19 05:46:42 2011
 
 <[email-masked]>; bh=NcyWFiDPY2Mj7Bj74rRkMsdleYWveUddLaHlUrDhNyI=; b=X51qPXpFVgQf956M1tzBuXpIuVkkzTc7UhgQf+rhhyK14iuY1BFEv5em K8xynxUQ/6pgTnCyuqxZReLsOimAfOFlKUFZF0hNGz9mf5hpqKft1/FOr kO7n4BRc75whZhn;
From: Ray Bellis <[email-masked]>
To: Wouter Cloetens <[email-masked]>
Date: Tue, 19 Jul 2011 12:46:35 +0000
Accept-Language: en-GB, en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [homenet] Idea regarding IPv6 RDNS on residential gateways

--_000_1CBC367CAF834C25A70CE30FD7DE8333nominetorguk_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

On 19 Jul 2011, at 13:10, Wouter Cloetens wrote:

RFC's, the IETF, and leading equipment vendors have the responsibility and the task to implement correctly and educate, so the implementations are done right. ;-)

Indeed.

Or do you think we shouldn't bother because people will implement it wrong any way?

I think the risks will outweigh the potential benefits.  [see below].

I think we should publish clear, thoroughly thought through, closed specs, _before_ anyone starts implementing this in their own goofy way. Not publish a "you shouldn't do that" RFC afterwards. So: "oh god, please yes, now!"

FWIW, I don't think any of the stuff I wrote up in RFC 5625 was the result of ambiguous or unclear specifications in prior RFCs.

My best guess is that the bulk of the flaws documented were simply due to a lack of familiarity with the full _range_ of DNS related RFCs, exacerbated by the need to deliver products on very slim margins.

I'm personally responsible for fixing that hole in a broken implementation from another vendor. I'm well aware of the risks

Excellent :)

Hence the security section, and the two layers of defence. Even if there is a CPE out there with an exploitable security hole, restrict the source addresses of the DNS requests to the DNS relays of the ISP.

The draft appears to mix up two DNS terms of art.

In particular, _delegation_ in the DNS protocol specifically refers to the act of publishing NS records, which then direct _recursive_ resolvers where to go for each iterative hop through the chain of NS records.

In a properly delegated model, the queries to the CPE would arrive from anywhere on the internet, not just from the ISP's DNS servers.

What you appear to be suggesting instead is that the _authoritative_ servers operated by the ISP should iteratively query these downstream CPE.

Authoritative servers are typically designed to provide answers as quickly as possible, usually from local storage or memory.  They do not perform any downstream queries.

Having an authoritative server perform downstream lookups will consume resources which may prevent it from serving local content efficiently and potentially lead to denial of service conditions.

kind regards,

Ray

--_000_1CBC367CAF834C25A70CE30FD7DE8333nominetorguk_
Content-Type: text/html; charset="us-ascii"
Content-ID: <08765738-81ff-4981-a5a2-7873862c5e54>
Content-Transfer-Encoding: quoted-printable

<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 19 Jul 2011, at 13:10, Wouter Cloetens wrote:</div><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font>RFC's, the IETF, and leading equipment vendors have the responsibility and the task to implement correctly and educate, so the implementations are done right. ;-)<br></div></blockquote><div><br></div>Indeed.</div><div><br><blockquote type="cite"><div>Or do you think we shouldn't bother because people will implement it wrong any way? </div></blockquote><div><br></div>I think the risks will outweigh the potential benefits. &nbsp;[see below].</div><div><br><blockquote type="cite"><div>I think we should publish clear, thoroughly thought through, closed specs, _before_ anyone starts implementing this in their own goofy way. Not publish a &quot;you shouldn't do that&quot; RFC afterwards. So: &quot;oh god, please yes, now!&quot;<br></div></blockquote><div><br></div></div><div>FWIW, I don't think any of the stuff I wrote up in RFC 5625 was the result of ambiguous or unclear specifications in prior RFCs.</div><div><br></div><div>My best guess is that the bulk of the flaws documented were simply due to a lack of familiarity with the full _range_ of DNS related RFCs, exacerbated by the need to deliver products on very slim margins.</div><div><br></div><div><blockquote type="cite"><div>I'm personally responsible for fixing that hole in a broken implementation from another vendor. I'm well aware of the risks<br></div></blockquote><div><br></div>Excellent :)</div><div><br><blockquote type="cite"><div>Hence the security section, and the two layers of defence. Even if there is a CPE out there with an exploitable security hole, restrict the source addresses of the DNS requests to the DNS relays of the ISP.<br></div></blockquote></div><br><div>The draft appears to mix up two DNS terms of art.</div><div><br></div><div>In particular, _delegation_ in the DNS protocol specifically refers to the act of publishing NS records, which then direct _recursive_ resolvers where to go for each iterative hop through the chain of NS records.</div><div><br></div><div>In a properly delegated model, the queries to the CPE would arrive from anywhere on the internet, not just from the ISP's DNS servers.</div><div><br></div><div>What you appear to be suggesting instead is that the _authoritative_ servers operated by the ISP should iteratively query these downstream CPE.</div><div><br></div><div>Authoritative servers are typically designed to provide answers as quickly as possible, usually from local storage or memory. &nbsp;They do not perform any downstream queries.</div><div><br></div><div>Having an authoritative server perform downstream lookups will consume resources which may prevent it from serving local content efficiently and potentially lead to denial of service conditions.</div><div><br></div><div>kind regards,</div><div><br></div><div>Ray</div><div><br></div><div><br></div></body></html>
--_000_1CBC367CAF834C25A70CE30FD7DE8333nominetorguk_--

From [email-masked]  Tue Jul 19 06:21:09 2011
From: Sander Steffann <[email-masked]>
Date: Tue, 19 Jul 2011 15:04:12 +0200
To: Ray Bellis <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Wouter Cloetens <[email-masked]>
Subject: Re: [homenet] Idea regarding IPv6 RDNS on residential gateways

Hi,

> In a properly delegated model, the queries to the CPE would arrive from anywhere on the internet, not just from the ISP's DNS servers.
> 
> What you appear to be suggesting instead is that the _authoritative_ servers operated by the ISP should iteratively query these downstream CPE.
> 
> Authoritative servers are typically designed to provide answers as quickly as possible, usually from local storage or memory.  They do not perform any downstream queries.
> 
> Having an authoritative server perform downstream lookups will consume resources which may prevent it from serving local content efficiently and potentially lead to denial of service conditions.

So it needs to be rewritten to use AXFR/IXFR with UPDATEs :)
Sander

From [email-masked]  Tue Jul 19 09:02:22 2011
From: IESG Secretary <[email-masked]>
To: IETF Announcement list <[email-masked]>
Date: Tue, 19 Jul 2011 09:02:22 -0700 (PDT)
Cc: [email-masked], [email-masked]
Subject: [homenet] WG Action: Home Networks (homenet)

A new IETF working group has been formed in the Internet Area.  For 
additional information, please contact the Area Directors or the WG 
Chair.

Home Networks (homenet)
---------------------------------------------------
Current Status: Active Working Group

Chair:
  Mark Townsley <townsley at cisco.com>

Internet Area Directors:
  Ralph Droms <rdroms.ietf at gmail.com>
  Jari Arkko <jari.arkko at piuha.net>

Internet Area Advisor:
  Ralph Droms <rdroms.ietf at gmail.com>

Mailing Lists:
General Discussion:  [email-masked]
To Subscribe:        https://www.ietf.org/mailman/listinfo/homenet
Archive:             http://www.ietf.org/mail-archive/web/homenet/

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 for the home. 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, as appropriate. 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 group should assume that an IPv4 network may have
to co-exist alongside the IPv6 network and should take this into
account insofar as alignment with IPv6 is desirable. But the group
should also ensure that even IPv6-only are possible, and while
IP-version agnostic work is of course desirable, IPv4-specific work is
outside the scope of the group.

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 liason 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, 
as is understanding existing technology from these groups.

Goals and 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 [email-masked]  Tue Jul 19 10:27:49 2011
Date: Tue, 19 Jul 2011 09:27:46 -0800 (AKDT)
From: "Mr. James W. Laferriere" <[email-masked]>
To: [email-masked]
Subject: [homenet] Please ignore ,  Testing fileter configuration .  Tnx.

From [email-masked]  Tue Jul 19 10:40:26 2011
From: "Griffiths, Chris" <[email-masked]>
To: Wouter Cloetens <[email-masked]>, Arturo Servin <[email-masked]>
Date: Tue, 19 Jul 2011 17:40:13 +0000
Accept-Language: en-US
Cc: "<[email-masked]>" <[email-masked]>
Subject: Re: [homenet] Idea regarding IPv6 RDNS on residential gateways

On 7/19/11 8:16 AM, "Wouter Cloetens" <[email-masked]>
wrote:

>On 19/07/11 14:09, Arturo Servin wrote:
>> 	Wouldn't this create LAME delegations when the CPE is off?
>
>Caching will catch a fraction of that, but yes, that can't be avoided in
>my proposal.
>Is that a problem? It will just result in a time-out.
>
>Would it be more desirable for the network to detect that the CPE is no
>longer present, and automatically reconfigure the domain to
>authoritatively responding "not found" instead of delegating?

Given the size and magnitude of potentially hundreds of thousands of
devices offline at any given time, and in an outage situation possibly
millions in a large ISP environment, you could be looking at potentially
causing massive resource issues on the authoritative servers due to lame
delegations and the associated retries from caching resolvers.  Without a
mechanism to remove the delegation when the system stops responding and/or
turns off, this potentially becomes a big problem.  I think we need to
make sure that the delegation is removed when the device goes
offline/stops responding.  I like the idea, but currently many edge
devices will not support this configuration.  

From [email-masked]  Tue Jul 19 10:53:58 2011
Content-class: urn:content-classes:message
Date: Tue, 19 Jul 2011 13:53:51 -0400
From: "STARK, BARBARA H (ATTSI)" <[email-masked]>
To: "Griffiths, Chris" <[email-masked]>, "Wouter Cloetens" <[email-masked]>, "Arturo Servin" <[email-masked]>
Cc: [email-masked]
Subject: Re: [homenet] Idea regarding IPv6 RDNS on residential gateways

As an individual, I really don't want a domain name that's tied to my
access provider's domain. I want a domain name that I can take anywhere
I want. For me, something that would let me get a Dynamic DNS domain
from my home gateway, and then attach the hosts in my home network to
that DDNS domain and be able to (somehow) achieve resolution to host
addresses, would be much more compelling.

The less I can be dependent on my access provider, the happier I am. :)
Barbara

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Griffiths, Chris
> Sent: Tuesday, July 19, 2011 1:40 PM
> To: Wouter Cloetens; Arturo Servin
> Cc: <[email-masked]>
> Subject: Re: [homenet] Idea regarding IPv6 RDNS on residential
gateways
> 
> On 7/19/11 8:16 AM, "Wouter Cloetens" <[email-masked]>
> wrote:
> 
> 
> >On 19/07/11 14:09, Arturo Servin wrote:
> >> 	Wouldn't this create LAME delegations when the CPE is off?
> >
> >Caching will catch a fraction of that, but yes, that can't be avoided
> in
> >my proposal.
> >Is that a problem? It will just result in a time-out.
> >
> >Would it be more desirable for the network to detect that the CPE is
> no
> >longer present, and automatically reconfigure the domain to
> >authoritatively responding "not found" instead of delegating?
> 
> Given the size and magnitude of potentially hundreds of thousands of
> devices offline at any given time, and in an outage situation possibly
> millions in a large ISP environment, you could be looking at
> potentially
> causing massive resource issues on the authoritative servers due to
> lame
> delegations and the associated retries from caching resolvers.
Without
> a
> mechanism to remove the delegation when the system stops responding
> and/or
> turns off, this potentially becomes a big problem.  I think we need to
> make sure that the delegation is removed when the device goes
> offline/stops responding.  I like the idea, but currently many edge
> devices will not support this configuration.
> 
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

From [email-masked]  Tue Jul 19 11:29:15 2011
From: David R Oran <[email-masked]>
Date: Tue, 19 Jul 2011 14:28:55 -0400
To: "STARK, BARBARA H (ATTSI)" <[email-masked]>
Cc: [email-masked], "Griffiths, Chris" <[email-masked]>, Wouter Cloetens <[email-masked]>, Arturo Servin <[email-masked]>
Subject: Re: [homenet] Idea regarding IPv6 RDNS on residential gateways

+1
This is right on. Finding a low-touch way to get a home domain name is important in and of itself, and can be leveraged into a ton of useful things at higher layers.

On Jul 19, 2011, at 1:53 PM, STARK, BARBARA H (ATTSI) wrote:

> As an individual, I really don't want a domain name that's tied to my
> access provider's domain. I want a domain name that I can take anywhere
> I want. For me, something that would let me get a Dynamic DNS domain
> from my home gateway, and then attach the hosts in my home network to
> that DDNS domain and be able to (somehow) achieve resolution to host
> addresses, would be much more compelling.
> 
> The less I can be dependent on my access provider, the happier I am. :)
> Barbara
> 
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of Griffiths, Chris
>> Sent: Tuesday, July 19, 2011 1:40 PM
>> To: Wouter Cloetens; Arturo Servin
>> Cc: <[email-masked]>
>> Subject: Re: [homenet] Idea regarding IPv6 RDNS on residential
> gateways
>> 
>> On 7/19/11 8:16 AM, "Wouter Cloetens" <[email-masked]>
>> wrote:
>> 
>> 
>>> On 19/07/11 14:09, Arturo Servin wrote:
>>>> 	Wouldn't this create LAME delegations when the CPE is off?
>>> 
>>> Caching will catch a fraction of that, but yes, that can't be avoided
>> in
>>> my proposal.
>>> Is that a problem? It will just result in a time-out.
>>> 
>>> Would it be more desirable for the network to detect that the CPE is
>> no
>>> longer present, and automatically reconfigure the domain to
>>> authoritatively responding "not found" instead of delegating?
>> 
>> Given the size and magnitude of potentially hundreds of thousands of
>> devices offline at any given time, and in an outage situation possibly
>> millions in a large ISP environment, you could be looking at
>> potentially
>> causing massive resource issues on the authoritative servers due to
>> lame
>> delegations and the associated retries from caching resolvers.
> Without
>> a
>> mechanism to remove the delegation when the system stops responding
>> and/or
>> turns off, this potentially becomes a big problem.  I think we need to
>> make sure that the delegation is removed when the device goes
>> offline/stops responding.  I like the idea, but currently many edge
>> devices will not support this configuration.
>> 
>> _______________________________________________
>> homenet mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/homenet
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

From [email-masked]  Tue Jul 19 12:00:28 2011
From: "Howard, Lee" <[email-masked]>
To: "STARK, BARBARA H (ATTSI)" <[email-masked]>, "Griffiths, Chris" <[email-masked]>, Wouter Cloetens <[email-masked]>, Arturo Servin <[email-masked]>
Date: Tue, 19 Jul 2011 15:00:09 -0400
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [homenet] Idea regarding IPv6 RDNS on residential gateways

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> STARK, BARBARA H (ATTSI)
> Sent: Tuesday, July 19, 2011 1:54 PM
> To: Griffiths, Chris; Wouter Cloetens; Arturo Servin
> Cc: [email-masked]
> Subject: Re: [homenet] Idea regarding IPv6 RDNS on residential gateways
>
> As an individual, I really don't want a domain name that's tied to my
> access provider's domain. I want a domain name that I can take anywhere
> I want. For me, something that would let me get a Dynamic DNS domain
> from my home gateway, and then attach the hosts in my home network to
> that DDNS domain and be able to (somehow) achieve resolution to host
> addresses, would be much more compelling.

I think the first part is easily incorporated with some wording changes:

--
3.  DNS Delegation

A network operation can delegate authority for a domain to the CPE routers.
This domain name would be a name registered by the user, whether a
subdomain of the operator, or a unique domain name.
For example, a network operator could designate "customer.example.net"
for customer use.  A user could register "foo" and note the address of the
home gateway (or determine it from an account identifier).  The operator can
then delegate authority for "foo.example.net" to that gateway address.
Authority for the reverse zone for the customer's delegated prefix(es) are also
delegated to the gateway, as well as authority for the gateway's upstream
interface address.
--

As implied from expire draft-howard-isp-ip6rdns, one concern is the kind
of language users might choose for their subdomains.  If Barbara is required
to bring her own domain name, that problem is solved; the ISP is simply
providing NS records.

Lee

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 [email-masked]  Tue Jul 19 12:21:02 2011
From: "Howard, Lee" <[email-masked]>
To: Wouter Cloetens <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 19 Jul 2011 15:20:47 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [homenet] Idea regarding IPv6 RDNS on residential gateways

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Wouter Cloetens
> Sent: Sunday, July 17, 2011 4:01 PM
> To: [email-masked]
> Subject: [homenet] Idea regarding IPv6 RDNS on residential gateways
>
> So, if the ISP's DNS infrastructure would delegate host name lookups
> recursively to the gateways, the problem is solved.

I'm having trouble parsing that sentence.  Is the ISP delegating authority
for a subdomain, or is the ISP's authoritative server doing lookups?  For
many ISPs, those are separate server farms.

I was going to assume you meant the ISP delegates authority for foo.example.net
and 0.0.0.0.0.0.f.0.8.b.d.0.1.0.0.2.IP6.ARPA. to the home gateway, but then
you wanted to create an ACL limiting which resolvers can do lookups on the
home gateway: "to let the CPE router restrict legal sources of DNS requests."
I would oppose a solution that assumes authoritative servers are resolvers.
Would you clarify?

You use the term "public IP address" in your proto-draft several times; this
term is meaningless in IPv6 :-)

I always worry about loading more functionality onto home gateways;
consumers are very price-sensitive on these.  Adding an authoritative server
will cost a little.  For it to parse dDNS and/or mDNS and/or uPNP name
learning costs a little more.  You need to add DNSSEC considerations, which
costs a bit more.

I oppose adding this functionality to the home gateway, for operational, not
technical reasons.

Lee

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 [email-masked]  Tue Jul 19 13:05:55 2011
From: "Livingood, Jason" <[email-masked]>
To: David R Oran <[email-masked]>, "STARK, BARBARA H (ATTSI)" <[email-masked]>
Date: Tue, 19 Jul 2011 20:05:48 +0000
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>, "Griffiths, Chris" <[email-masked]>, Wouter Cloetens <[email-masked]>, Arturo Servin <[email-masked]>
Subject: Re: [homenet] Idea regarding IPv6 RDNS on residential gateways

--_000_CA4B5B93300F4jasonlivingoodcablecomcastcom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

+1: this is an interesting use case to keep in mind

JL

On 7/19/11 2:28 PM, "David R Oran" <[email-masked]<mailto:[email-masked]>> wrote:

+1
This is right on. Finding a low-touch way to get a home domain name is important in and of itself, and can be leveraged into a ton of useful things at higher layers.

On Jul 19, 2011, at 1:53 PM, STARK, BARBARA H (ATTSI) wrote:

As an individual, I really don't want a domain name that's tied to my
access provider's domain. I want a domain name that I can take anywhere
I want. For me, something that would let me get a Dynamic DNS domain
from my home gateway, and then attach the hosts in my home network to
that DDNS domain and be able to (somehow) achieve resolution to host
addresses, would be much more compelling.
The less I can be dependent on my access provider, the happier I am. :)
Barbara
-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On
Behalf Of Griffiths, Chris
Sent: Tuesday, July 19, 2011 1:40 PM
To: Wouter Cloetens; Arturo Servin
Cc: <[email-masked]<mailto:[email-masked]>>
Subject: Re: [homenet] Idea regarding IPv6 RDNS on residential
gateways
On 7/19/11 8:16 AM, "Wouter Cloetens" <[email-masked]<mailto:[email-masked]>>
wrote:
On 19/07/11 14:09, Arturo Servin wrote:
Wouldn't this create LAME delegations when the CPE is off?
Caching will catch a fraction of that, but yes, that can't be avoided
in
my proposal.
Is that a problem? It will just result in a time-out.
Would it be more desirable for the network to detect that the CPE is
no
longer present, and automatically reconfigure the domain to
authoritatively responding "not found" instead of delegating?
Given the size and magnitude of potentially hundreds of thousands of
devices offline at any given time, and in an outage situation possibly
millions in a large ISP environment, you could be looking at
potentially
causing massive resource issues on the authoritative servers due to
lame
delegations and the associated retries from caching resolvers.
Without
a
mechanism to remove the delegation when the system stops responding
and/or
turns off, this potentially becomes a big problem.  I think we need to
make sure that the delegation is removed when the device goes
offline/stops responding.  I like the idea, but currently many edge
devices will not support this configuration.
_______________________________________________
homenet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/homenet
_______________________________________________
homenet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/homenet

_______________________________________________
homenet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/homenet

--_000_CA4B5B93300F4jasonlivingoodcablecomcastcom_
Content-Type: text/html; charset="us-ascii"
Content-ID: <[email-masked]>
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 16px; font-family: Calibri, sans-serif; ">
<div>
<div>&#43;1: this is an interesting use case to keep in mind</div>
</div>
<div><br>
</div>
<div>JL</div>
<div><br>
</div>
<div>On 7/19/11 2:28 PM, &quot;David R Oran&quot; &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt; wrote:</div>
<div><br>
</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>&#43;1</div>
<div>This is right on. Finding a low-touch way to get a home domain name is important in and of itself, and can be leveraged into a ton of useful things at higher layers.</div>
<div><br>
</div>
<div>On Jul 19, 2011, at 1:53 PM, STARK, BARBARA H (ATTSI) wrote:</div>
<div><br>
</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>As an individual, I really don't want a domain name that's tied to my</div>
<div>access provider's domain. I want a domain name that I can take anywhere</div>
<div>I want. For me, something that would let me get a Dynamic DNS domain</div>
<div>from my home gateway, and then attach the hosts in my home network to</div>
<div>that DDNS domain and be able to (somehow) achieve resolution to host</div>
<div>addresses, would be much more compelling.</div>
<div></div>
<div>The less I can be dependent on my access provider, the happier I am. :)</div>
<div>Barbara</div>
<div></div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>-----Original Message-----</div>
<div>From: <a href="mailto:[email-masked]">[email-masked]</a> [<a href="mailto:[email-masked]">mailto:[email-masked]</a>] On</div>
<div>Behalf Of Griffiths, Chris</div>
<div>Sent: Tuesday, July 19, 2011 1:40 PM</div>
<div>To: Wouter Cloetens; Arturo Servin</div>
<div>Cc: &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;</div>
<div>Subject: Re: [homenet] Idea regarding IPv6 RDNS on residential</div>
</blockquote>
<div>gateways</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div></div>
<div>On 7/19/11 8:16 AM, &quot;Wouter Cloetens&quot; &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;</div>
<div>wrote:</div>
<div></div>
<div></div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>On 19/07/11 14:09, Arturo Servin wrote:</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div><span class="Apple-tab-span" style="white-space:pre"></span>Wouldn't this create LAME delegations when the CPE is off?</div>
</blockquote>
<div></div>
<div>Caching will catch a fraction of that, but yes, that can't be avoided</div>
</blockquote>
<div>in</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>my proposal.</div>
<div>Is that a problem? It will just result in a time-out.</div>
<div></div>
<div>Would it be more desirable for the network to detect that the CPE is</div>
</blockquote>
<div>no</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>longer present, and automatically reconfigure the domain to</div>
<div>authoritatively responding &quot;not found&quot; instead of delegating?</div>
</blockquote>
<div></div>
<div>Given the size and magnitude of potentially hundreds of thousands of</div>
<div>devices offline at any given time, and in an outage situation possibly</div>
<div>millions in a large ISP environment, you could be looking at</div>
<div>potentially</div>
<div>causing massive resource issues on the authoritative servers due to</div>
<div>lame</div>
<div>delegations and the associated retries from caching resolvers.</div>
</blockquote>
<div>Without</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>a</div>
<div>mechanism to remove the delegation when the system stops responding</div>
<div>and/or</div>
<div>turns off, this potentially becomes a big problem.&nbsp;&nbsp;I think we need to</div>
<div>make sure that the delegation is removed when the device goes</div>
<div>offline/stops responding.&nbsp;&nbsp;I like the idea, but currently many edge</div>
<div>devices will not support this configuration.</div>
<div></div>
<div>_______________________________________________</div>
<div>homenet mailing list</div>
<div><a href="mailto:[email-masked]">[email-masked]</a></div>
<div><a href="https://www.ietf.org/mailman/listinfo/homenet">https://www.ietf.org/mailman/listinfo/homenet</a></div>
</blockquote>
<div>_______________________________________________</div>
<div>homenet mailing list</div>
<div><a href="mailto:[email-masked]">[email-masked]</a></div>
<div><a href="https://www.ietf.org/mailman/listinfo/homenet">https://www.ietf.org/mailman/listinfo/homenet</a></div>
</blockquote>
<div><br>
</div>
<div>_______________________________________________</div>
<div>homenet mailing list</div>
<div><a href="mailto:[email-masked]">[email-masked]</a></div>
<div><a href="https://www.ietf.org/mailman/listinfo/homenet">https://www.ietf.org/mailman/listinfo/homenet</a></div>
<div><br>
</div>
</blockquote>
</body>
</html>

--_000_CA4B5B93300F4jasonlivingoodcablecomcastcom_--

From [email-masked]  Tue Jul 19 14:26:28 2011
Date: Tue, 19 Jul 2011 23:26:17 +0200
From: Wouter Cloetens <[email-masked]>
To: "Howard, Lee" <[email-masked]>,  "[email-masked]" <[email-masked]>
Subject: Re: [homenet] Idea regarding IPv6 RDNS on residential gateways

On 19/07/11 21:20, Howard, Lee wrote:
>> So, if the ISP's DNS infrastructure would delegate host name lookups
>> recursively to the gateways, the problem is solved.
>
> I'm having trouble parsing that sentence.  Is the ISP delegating authority
> for a subdomain, or is the ISP's authoritative server doing lookups?  For
> many ISPs, those are separate server farms.
>
> I was going to assume you meant the ISP delegates authority for foo.example.net
> and 0.0.0.0.0.0.f.0.8.b.d.0.1.0.0.2.IP6.ARPA. to the home gateway, but then
> you wanted to create an ACL limiting which resolvers can do lookups on the
> home gateway: "to let the CPE router restrict legal sources of DNS requests."
> I would oppose a solution that assumes authoritative servers are resolvers.
> Would you clarify?

I didn't do my homework on that subject. Indeed, I'd want the ISP's DNS 
servers to perform the lookups on the home gateways, yet provide 
authoritative responses. While it's easy enough to hack together a DNS 
relay that works like this, this may not be a realistic approach.
If I drop the optional security feature of restricting the source 
address, delegation works.

> You use the term "public IP address" in your proto-draft several times; this
> term is meaningless in IPv6 :-)

Right; what was I thinking. I'll replace it with GUA or "WAN interface GUA."

> I always worry about loading more functionality onto home gateways;
> consumers are very price-sensitive on these.  Adding an authoritative server
> will cost a little.  For it to parse dDNS and/or mDNS and/or uPNP name
> learning costs a little more.  You need to add DNSSEC considerations, which
> costs a bit more.

Our product has done most of this for years; it's not a big deal.
CPU's get more powerful, RAM and flash gets bigger every year. The 
slowest thing out there is a 400MHz single-core MIPS CPU.
The introduction of NAND flash has pushed down prices on flash so much 
that shipping less than 64MiB isn't worth the effort.
For CPU power, look at it from this angle; in 2011, you want the CPE to 
have an integrated 4-port gigabit Ethernet switch and an 802.11n 
wireless LAN AP (up to 450Mbit/s theoretically), capable of routing and 
NAT'ing a wirespeed. Do you think a bit of DNS and device snooping is 
going to make a dent in the CPU load?
Development of the software is a non-recurrent engineering cost, which 
is trivial for a mass product. There's also a lot of open source 
software out there to cover the nitty-gritty of the protocols; you don't 
need to start from scratch.
RAM consumption is the only thing you might want to keep an eye on.

> I oppose adding this functionality to the home gateway, for operational, not
> technical reasons.

Operational on the network side, or in the CPE? I've got the CPE 
covered; that's my niche, don't worry about that. I'm missing the 
operator view. I've had some good feedback here already. Keep it coming.

How else would you tackle the problem, though? A dyndns-style service 
could hit a serious scalability issue if every device in every home and 
business in the world is going to trigger a registration request every 
time a delegated prefix changes. There could be more dyndns registration 
traffic than actual DNS lookups.

Not doing anything is the other option, if all the failed lookups don't 
bother you.

bfn, Wouter

From [email-masked]  Tue Jul 19 18:33:59 2011
To: "Griffiths, Chris" <[email-masked]>
From: Mark Andrews <[email-masked]>
Date: Wed, 20 Jul 2011 11:33:32 +1000
Cc: "<[email-masked]>" <[email-masked]>, Wouter Cloetens <[email-masked]>, Arturo Servin <[email-masked]>
Subject: Re: [homenet] Idea regarding IPv6 RDNS on residential gateways

	To do a reverse lookup you add a DNAME to something that
	is being served by servers that are up all the time.

	If the customer has prefix 2001:DB8:1234:65/56 then the CPE
	adds a DNAME record to customer.isp.com (or any other zone
	served by a dynamic DNS provider) using UPDATE.

	6.5.4.3.2.1.8.b.d.0.1.0.0.2.ip6.arpa. DNAME customer.isp.com.

	When the lease on the prefix delegation expires the ISP's DHCP
	server removes the DNAME.

	Adding a traditional delegation (NS records) pointing to
	the CPE equipment is not a good idea as it you need the
	reliability of multiple serves not behind a single point
	of failure.

	Machines register their AAAA and PTR records taking into
	account the DNAME when contructing the ownername of the PTR
	record.

host.customer.isp.com. AAAA 2001:DB8:1234:6500:befa:dead:beef:1234
4.3.2.1.f.e.e.b.d.a.e.d.a.f.e.b.0.0.customer.isp.com. PTR host.customer.isp.com.

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

From [email-masked]  Thu Jul 21 15:01:49 2011
From: Mark Townsley <[email-masked]>
Date: Fri, 22 Jul 2011 00:01:40 +0200
To: [email-masked]
Subject: [homenet] Note-taker?

If you are planning to be in homenet and can take notes, please step forward.

Thank you,

- Mark

From [email-masked]  Thu Jul 21 15:02:42 2011
From: Timothy Winters <[email-masked]>
Date: Thu, 21 Jul 2011 18:02:38 -0400
To: Mark Townsley <[email-masked]>
Cc: [email-masked]
Subject: Re: [homenet] Note-taker?

Hi Mark,
	I'd be happy to take notes.

~Tim

On Jul 21, 2011, at 6:01 PM, Mark Townsley wrote:

> 
> If you are planning to be in homenet and can take notes, please step forward.
> 
> Thank you,
> 
> - Mark
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

From [email-masked]  Fri Jul 22 13:18:32 2011
Auto-Submitted: auto-generated
From: [email-masked]
To: [email-masked]
Date: Fri, 22 Jul 2011 16:18:18 -0400
Subject: [homenet] Francis Bishop est absent(e).

Je serai absent(e) du  22/07/2011 au 23/07/2011.

Je suis � l'ext�rieur du bureau et je serai de retour le 9 ao�t 2011.
I am currently out of the office and I will be back on August 9th 2011.

Pour toutes questions urgentes, SVP vous adresser � :
MTA: Efrain Fino 514-372-5657
IPv6: Camilo Ruiz Palacios 514-759-2674

Please contact the following people for any emergencies.
MTA: Efrain Fino 514-372-5657
IPv6: Camilo Ruiz Palacios 514-759-2674

Francis Bishop

From [email-masked]  Mon Jul 25 14:00:02 2011
From: Ralph Droms <[email-masked]>
Date: Mon, 25 Jul 2011 16:59:59 -0400
To: [email-masked]
Subject: [homenet] homenet WG co-chair

I'm happy to announce that we've selected Ray Bellis to join Mark as co-chair of homenet. Ray will take on that role immediately, in time for the WG meeting this Wednesday.

We had several excellent candidates, and thanks to all of you who volunteered.  We appreciate your interest and willingness to serve as co-chair.  We're looking forward to your continued contribution to the success of the WG.

See you Wednesday...

- Jari and Ralph

From [email-masked]  Tue Jul 26 10:05:05 2011
From: Ray Bellis <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Tue, 26 Jul 2011 17:04:51 +0000
Accept-Language: en-GB, en-US
Subject: [homenet] Jabber scribe?

If we could also please have an advance volunteer (or two) for Jabber scribe that would be much appreciated.

thanks,

Ray

From [email-masked]  Tue Jul 26 20:22:04 2011
From: Mark Townsley <[email-masked]>
Date: Tue, 26 Jul 2011 23:21:13 -0400
To: [email-masked]
Subject: Re: [homenet] Jabber scribe?

We have Timothy Winters, Dave Oran, and Stuart Cheshire all willing to take notes. Thanks to all of you.

Could we have a jabber volunteer, or could one of the 3 folks above be the jabber scribe instead?

Thank you,

- Mark & Ray

On Jul 26, 2011, at 1:04 PM, Ray Bellis wrote:

> If we could also please have an advance volunteer (or two) for Jabber scribe that would be much appreciated.
> 
> thanks,
> 
> Ray
> 
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

From [email-masked]  Wed Jul 27 04:38:32 2011
From: Ray Bellis <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Wed, 27 Jul 2011 11:38:27 +0000
Accept-Language: en-GB, en-US
Subject: [homenet] Updated Agenda

Please note that the Agenda for this afternoon's meeting has been updated as below.

The HTML version, including links to the presentations (once we have them - hint, hint...) is at http://tools.ietf.org/wg/homenet/agenda

Ray & Mark

--8<--8<--

Administrivia 
-------------

1300-1315 (20m) - Chairs

  o  Note Well, Scribes, Blue sheets
  o  Introduction

Architecture
------------

1320-1350 (30m) - Jari Arkko

  o  draft-arkko-townsley-homenet-arch-00 

see also:

  o  RFC 6204
  o  draft-ietf-v6ops-ipv6-cpe-router-bis-01

Prefix Configuration & Managing Routing
---------------------------------------

1350-1415 (25m) - Fred Baker

  o  draft-baker-fun-multi-router-00
  o  draft-baker-fun-routing-class-00

see also:

  o  draft-herbst-v6ops-cpeenhancements-00

Network Security
----------------

1415-1435 (20m) - Chris Palmer

  o  security within the local site
  o  security from outside of the local site

Name Resolution
---------------

1435-1455 (20m) - Chris Griffiths

  o  Name resolution of local hosts
     - from inside
     - from outside
     - http://e2big.org/ietf/draft-cloetens-homenet-dns-delegation

see also:

  o  RFC 6092
  o  draft-vyncke-advanced-ipv6-security-02

Service Discovery
-----------------

No presentation at this meeting

Wrap Up
-------

1455-1500 (5m) - Chairs, ADs

  o  Conclusions, Next Steps

--8<--8<--

From [email-masked]  Wed Jul 27 10:51:38 2011
From: "Howard, Lee" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Wed, 27 Jul 2011 13:51:24 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: [homenet] draft-arkko-townsley-homenet-arch comments

--_000_DCC302FAA9FE5F4BBA4DCAD465693779144B01BB42PRVPEXVS03cor_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Good document; it frames the context well.

It is important to get the principles correct, because they will form the basis for judging the goodness of future work.  I don't agree with all of the enumerated principles as written.  Some may just require clarification.
Largest possible subnets.  From Jari's slide discussion, I think this means "largest possible L2 domains" and not "shortest possible prefix length."  The use of "LAN" and "subnet" without definition is confusing, especially given that "LAN" is used differently in draft-baker-fun-multi-router.

Transparent end-to-end.   This principle is good, as long as "addressable" very clearly does not imply "reachable."  We have not adopted draft-vynke-advanced-security, and even if we do, there are good cases for use of firewalls and/or ACLs.

IP connectivity between all nodes.  Connectivity sounds like reachability, which is often a good thing, but not universally.  I'm confused about requiring "IP-layer connectivity" "at the link layer, if possible, and using routing at the IP layer  otherwise."  Which layer?

Intelligent policy.  Little should be hard-coded, but this could be clarified-as written, it could be taken to mean that queue management is forbidden.  It is also unclear how policies could be "driven off up-to-date databases in the Internet."  I think this is begging the question-assuming advanced-security is the best solution by defining the problem as requiring advanced-security.

Lee Howard
Director of Network Technology
Time Warner Cable
(703) 345-3513
[email-masked]

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

--_000_DCC302FAA9FE5F4BBA4DCAD465693779144B01BB42PRVPEXVS03cor_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Times New Roman","serif";
	color:black;
	font-weight:normal;
	font-style:normal;
	text-decoration:none none;}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:"Courier New";}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:&quot;Times New Roman&quot;,&quot;serif&quot;;color:black">Good document; it frames the context well.&nbsp;&nbsp;
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:&quot;Times New Roman&quot;,&quot;serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:&quot;Times New Roman&quot;,&quot;serif&quot;;color:black">It is important to get the principles correct, because they will form the basis for judging the goodness of future work.&nbsp; I don't agree with all of the enumerated
 principles as written.&nbsp; Some may just require clarification.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:&quot;Times New Roman&quot;,&quot;serif&quot;;color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:&quot;Times New Roman&quot;,&quot;serif&quot;;color:black">Largest possible subnets.&nbsp; From Jari's slide discussion, I think this means &quot;largest possible L2 domains&quot; and not &quot;shortest possible prefix length.&quot;&nbsp; The use
 of &quot;LAN&quot; and &quot;subnet&quot; without definition is confusing, especially given that &quot;LAN&quot; is used differently in draft-baker-fun-multi-router.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:&quot;Times New Roman&quot;,&quot;serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:&quot;Times New Roman&quot;,&quot;serif&quot;;color:black">Transparent end-to-end.&nbsp;&nbsp; This principle is good, as long as &quot;addressable&quot; very clearly does not imply &quot;reachable.&quot;&nbsp; We have not adopted draft-vynke-advanced-security,
 and even if we do, there are good cases for use of firewalls and/or ACLs.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:&quot;Times New Roman&quot;,&quot;serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p>
<pre><span style="font-size:12.0pt;font-family:&quot;Times New Roman&quot;,&quot;serif&quot;;color:black">IP connectivity between all nodes.&nbsp; Connectivity sounds like reachability, which is often a good thing, but not universally.&nbsp; I'm confused about requiring &quot;IP-layer connectivity&quot; &quot;at the link layer, if possible, </span><span style="font-size:12.0pt;font-family:&quot;Times New Roman&quot;,&quot;serif&quot;">and using routing at the IP layer&nbsp; otherwise.&quot;&nbsp; Which layer?<o:p></o:p></span></pre>
<pre><span style="font-size:12.0pt;font-family:&quot;Times New Roman&quot;,&quot;serif&quot;"><o:p>&nbsp;</o:p></span></pre>
<pre><span style="font-size:12.0pt;font-family:&quot;Times New Roman&quot;,&quot;serif&quot;">Intelligent policy.&nbsp; Little should be hard-coded, but this could be clarified&#8212;as written, it could be taken to mean that queue management is forbidden.&nbsp; It is also unclear how policies could be &quot;driven off up-to-date databases in the Internet.&quot;&nbsp; I think this is begging the question&#8212;assuming advanced-security is the best solution by defining the problem as requiring advanced-security.<o:p></o:p></span></pre>
<pre><span style="font-size:12.0pt;font-family:&quot;Times New Roman&quot;,&quot;serif&quot;"><o:p>&nbsp;</o:p></span></pre>
<pre><span style="font-size:12.0pt;font-family:&quot;Times New Roman&quot;,&quot;serif&quot;"><o:p>&nbsp;</o:p></span></pre>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:&quot;Times New Roman&quot;,&quot;serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span lang="EN" style="font-size:12.0pt;font-family:&quot;Times New Roman&quot;,&quot;serif&quot;;color:black">Lee Howard<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN" style="font-size:12.0pt;font-family:&quot;Times New Roman&quot;,&quot;serif&quot;;color:black">Director of&nbsp;Network Technology<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN" style="font-size:12.0pt;font-family:&quot;Times New Roman&quot;,&quot;serif&quot;;color:black">Time Warner Cable<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN" style="font-size:12.0pt;font-family:&quot;Times New Roman&quot;,&quot;serif&quot;;color:black">(703) 345-3513<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN" style="font-size:12.0pt;font-family:&quot;Times New Roman&quot;,&quot;serif&quot;;color:black">[email-masked]</span><span style="font-size:12.0pt;font-family:&quot;Times New Roman&quot;,&quot;serif&quot;;color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<br>
<hr>
<font face="Arial" color="Gray" size="1">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.<br>
</font>
</body>
</html>

--_000_DCC302FAA9FE5F4BBA4DCAD465693779144B01BB42PRVPEXVS03cor_--

From [email-masked]  Wed Jul 27 12:13:46 2011
From: Ray Bellis <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Wed, 27 Jul 2011 19:13:40 +0000
Accept-Language: en-GB, en-US
Subject: [homenet] USB clicker

If you're the person who kindly lent us your USB clicker but left without it, please retrieve it from the IETF registration desk.

thanks,

Ray

From [email-masked]  Wed Jul 27 15:49:12 2011
From: Fred Baker <[email-masked]>
Date: Wed, 27 Jul 2011 18:49:09 -0400
To: Ray Bellis <[email-masked]>, Stuart Cheshire <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [homenet] USB clicker

On Jul 27, 2011, at 3:13 PM, Ray Bellis wrote:

> If you're the person who kindly lent us your USB clicker but left without it, please retrieve it from the IETF registration desk.

Likely Stuart...

> thanks,
> 
> Ray
> 
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

From [email-masked]  Wed Jul 27 16:11:46 2011
From: Ray Bellis <[email-masked]>
To: Fred Baker <[email-masked]>
Date: Wed, 27 Jul 2011 23:11:26 +0000
Accept-Language: en-GB, en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [homenet] USB clicker

--_000_A3E44219E294497FB46AAFB9C10A555Anominetorguk_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Likely Stuart...

No, Stuart got his back.

I'm told by the registration desk that the device in question was already reunited with its owner.

thanks,

Ray

--_000_A3E44219E294497FB46AAFB9C10A555Anominetorguk_
Content-Type: text/html; charset="us-ascii"
Content-ID: <aa1b8370-46e3-4c2e-902a-e2973f5478d0>
Content-Transfer-Encoding: quoted-printable

<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><blockquote type="cite"><div><br>Likely Stuart...<br><font class="Apple-style-span" color="#007b09"><br></font></div></blockquote><br></div><div><br></div><div>No, Stuart got his back.</div><div><br></div><div>I'm told by the registration desk that the device in question was already reunited with its owner.</div><div><br></div><div>thanks,</div><div><br></div><div>Ray</div><div><br></div><br></body></html>
--_000_A3E44219E294497FB46AAFB9C10A555Anominetorguk_--

From [email-masked]  Thu Jul 28 09:00:40 2011
From: Joel Jaeggli <[email-masked]>
Date: Thu, 28 Jul 2011 12:00:35 -0400
To: [email-masked]
Subject: [homenet] Fwd: [v6ops] default LAN routing protocol for IPv6 CE router

--Apple-Mail-32-701670642
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii

Begin forwarded message:

> From: Don Sturek <[email-masked]>
> Date: July 28, 2011 11:53:04 AM EDT
> To: Joel Jaeggli <[email-masked]>, Shishio Tsuchiya <[email-masked]>
> Cc: <[email-masked]>
> Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router
> 
> Hi Joel,
> 
> I think the third point on desirability of a path is key.  The routing
> protocol should avoid constrained paths like 802.15.4 mesh networks in
> favor of longer routes through technologies like Wi-Fi or Ethernet.  We
> need to define appropriate routing metrics to make this happen.
> 
> Also, new subnets will be added by the homeowner in an ad hoc fashion and
> new path characteristics must be determined automatically and factored
> into new routing paths.
> 
> The idea would be to use some off the shelf existing routing protocol as
> is and maybe work on some intelligence on path cost (this topic might be
> an interesting one for Homenet).
> 
> Don
> 
> 
> 
> 
> On 7/28/11 8:18 AM, "Joel Jaeggli" <[email-masked]> wrote:
> 
>> 
>> On Jul 27, 2011, at 2:21 PM, Shishio Tsuchiya wrote:
>> 
>>> Mikael
>>> Mikael Abrahamsson wrote:
>>>> On Wed, 27 Jul 2011, Shishio Tsuchiya wrote:
>>>> 
>>>>> I think OSPFv3 is not acceptable as default routing protocol on CPE
>>>>> router.
>>>> 
>>>> Care to elaborate on that?
>>>> 
>>> 
>>> Most of home gateway supports only RIPv1/v2 as IPv4 routing protocol.
>>> The reasons are..
>>> -OSPF consumes CPU/memory than RIP.
>>> -OSPF operetaion is needed more knowledge compare with RIP.
>>> The character of these protocol does not change on IPv6 environment,too.
>>> So we thought RIPng would be acceptable routing protocol for IPv6 CPE
>>> router,also.
>> 
>> So, if one is working with requirements rather than working backwards
>> from a selected protocol one would suppose that some of the requirements
>> might look something like:
>> 
>> * can be used with acceptable defaults (e.g. no configuration)
>> * has sensive safeguards to prevent interaction with isp IGP.
>> * can distinguish between the desirability of a path on the basis of
>> something other than hop count. e.g. just because I happen to have
>> connected an 802.5.14 network to two largely ethernet devices doesn't
>> mean traffic to other parts of the network should traverse the former
>> when it happens to be the best path.
>> 
>>> Regards,
>>> -Shishio
>>> _______________________________________________
>>> v6ops mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/v6ops
>>> 
>> 
>> _______________________________________________
>> v6ops mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/v6ops
> 
> 

--Apple-Mail-32-701670642
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><br><div>Begin forwarded message:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1);"><b>From: </b></span><span style="font-family:'Helvetica'; font-size:medium;">Don Sturek &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1);"><b>Date: </b></span><span style="font-family:'Helvetica'; font-size:medium;">July 28, 2011 11:53:04 AM EDT<br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1);"><b>To: </b></span><span style="font-family:'Helvetica'; font-size:medium;">Joel Jaeggli &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;, Shishio Tsuchiya &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1);"><b>Cc: </b></span><span style="font-family:'Helvetica'; font-size:medium;">&lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1);"><b>Subject: </b></span><span style="font-family:'Helvetica'; font-size:medium;"><b>Re: [v6ops] default LAN routing protocol for IPv6 CE router</b><br></span></div><br><div>Hi Joel,<br><br>I think the third point on desirability of a path is key. &nbsp;The routing<br>protocol should avoid constrained paths like 802.15.4 mesh networks in<br>favor of longer routes through technologies like Wi-Fi or Ethernet. &nbsp;We<br>need to define appropriate routing metrics to make this happen.<br><br>Also, new subnets will be added by the homeowner in an ad hoc fashion and<br>new path characteristics must be determined automatically and factored<br>into new routing paths.<br><br>The idea would be to use some off the shelf existing routing protocol as<br>is and maybe work on some intelligence on path cost (this topic might be<br>an interesting one for Homenet).<br><br>Don<br><br><br><br><br>On 7/28/11 8:18 AM, "Joel Jaeggli" &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt; wrote:<br><br><blockquote type="cite"><br></blockquote><blockquote type="cite">On Jul 27, 2011, at 2:21 PM, Shishio Tsuchiya wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">Mikael<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Mikael Abrahamsson wrote:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">On Wed, 27 Jul 2011, Shishio Tsuchiya wrote:<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I think OSPFv3 is not acceptable as default routing protocol on CPE<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">router.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Care to elaborate on that?<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Most of home gateway supports only RIPv1/v2 as IPv4 routing protocol.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">The reasons are..<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">-OSPF consumes CPU/memory than RIP.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">-OSPF operetaion is needed more knowledge compare with RIP.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">The character of these protocol does not change on IPv6 environment,too.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">So we thought RIPng would be acceptable routing protocol for IPv6 CPE<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">router,also.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">So, if one is working with requirements rather than working backwards<br></blockquote><blockquote type="cite">from a selected protocol one would suppose that some of the requirements<br></blockquote><blockquote type="cite">might look something like:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">* can be used with acceptable defaults (e.g. no configuration)<br></blockquote><blockquote type="cite">* has sensive safeguards to prevent interaction with isp IGP.<br></blockquote><blockquote type="cite">* can distinguish between the desirability of a path on the basis of<br></blockquote><blockquote type="cite">something other than hop count. e.g. just because I happen to have<br></blockquote><blockquote type="cite">connected an 802.5.14 network to two largely ethernet devices doesn't<br></blockquote><blockquote type="cite">mean traffic to other parts of the network should traverse the former<br></blockquote><blockquote type="cite">when it happens to be the best path.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">Regards,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">-Shishio<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">_______________________________________________<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">v6ops mailing list<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><a href="mailto:[email-masked]">[email-masked]</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><a href="https://www.ietf.org/mailman/listinfo/v6ops">https://www.ietf.org/mailman/listinfo/v6ops</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite">v6ops mailing list<br></blockquote><blockquote type="cite"><a href="mailto:[email-masked]">[email-masked]</a><br></blockquote><blockquote type="cite"><a href="https://www.ietf.org/mailman/listinfo/v6ops">https://www.ietf.org/mailman/listinfo/v6ops</a><br></blockquote><br><br></div></blockquote></div><br></body></html>
--Apple-Mail-32-701670642--