HOMENET working group proposal

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

HOMENET is a new working group proposal, a variation of the 
HOMEGATE/HOMENET theme that we discussed last year, but this time 
looking at it from a different angle. The old effort was mostly focused 
about what home gateways should do: forwarding, transport, and DNS 
proxying issues. The new effort is about home networks themselves, in 
particular what kind of network architecture and configuration is 
necessary to support IPv6-based home networks. We view IPv4-based home 
networks as "done" at this time (or perhaps as "cannot be changed anyway").

I have been discussing this effort in the background for the last couple 
of month with Mark Townsley and others, and more publicly since early 
June. The proposal has been brought to the IESG, IAB and some 
directorates for discussion, and we've been going back and forth whether 
this is ready to become a working group or needs to be run as a BOF in 
Quebec City. The current plan is that the working group proposal goes to 
IETF-wide review this week, and if the feedback from the community, IAB, 
and the IESG is positive, we will create the working group just in time 
for the IETF. Otherwise, the slot reserved in the agenda for the meeting 
will be used to run the proposal as a BOF.

In any case, I would like to solicit discussion on this topic, and 
perhaps some early drafts as well. Please comment on the charter at 
least. Go here to subscribe https://www.ietf.org/mailman/listinfo/fun 
and below you can find the most recent charter proposal. Please join the 
list and the discussion.

Note that the new proposal was called FUN at the time that we created 
the list. It has now been renamed back to HOMENET to be more 
descriptive. The list will be renamed soon as well (current subscribers 
will stay). Note also that I'm sending this to the old homegate list, to 
inform people who were interested in that. I'd like the discussion to 
happen on the  list, however.

Jari

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

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

Chairs:
TBD

Internet Area Directors:
Ralph Droms 
Jari Arkko 

Internet Area Advisor:
Jari Arkko 

Routing Area Technical Advisor:
TBD

Security Area Technical Advisor:
TBD

Mailing Lists:
General Discussion: 
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

Hi, Jari,

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

Bellow you'll find some comments/questions about the proposed charter.
They are not an argument against or in favour of the creation of the
aforementioned wg, but rather comments and/or requests for clarification...On 06/29/2011 05:47 AM, Jari Arkko wrote:
[....]
> o Service providers are deploying IPv6, and support for IPv6 is
> increasingly available in home gateway devices. While IPv6 resembles
> IPv4 in many ways, it changes address allocation principles and allows
> direct IP addressability and routing to devices in the home from the
> Internet. This is a promising area in IPv6 that has proved challenging
> in IPv4 with the proliferation of NAT.NAT devices involve two related but different issues:
* address translation
* an implicit "allow only return traffic" firewall-like functionality

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

For instance (and of the top of my head), this functionality is even
proposed in the "simple security" requirements that had been produced by
v6ops.> o End-to-end communication is both an opportunity and a concern as it
> enables new applications but also exposes nodes in the internal
> networks to receipt of unwanted traffic from the Internet. Firewalls
> that restrict incoming connections may be used to prevent exposure,
> however, this reduces the efficacy of end-to-end connectivity that
> IPv6 has the potential to restore.I personally consider this property of "end-to-end connectivity" as
"gone". -- among other reasons, because it would require a change of
mindset. I'm more of the idea that people will replicate the
architecture of their IPv4 networks with IPv6, in which end-systems are
not reachable from the public Internet.

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

On Jun 29, 2011 7:19 PM, "Fernando Gont"  wrote:
>
> Hi, Jari,
>
> My high level comment/question is: the proposed charter seems to stress
> that IPv6 is the driver behind this potential wg effort... however, I
> think that this deserves more discussion -- it's not clear to me why/how
> typical IPv6 home networks would be much different from their IPv4
> counterparts.
>
> Bellow you'll find some comments/questions about the proposed charter.
> They are not an argument against or in favour of the creation of the
> aforementioned wg, but rather comments and/or requests forclarification...>
> On 06/29/2011 05:47 AM, Jari Arkko wrote:
> [....]
> > o Service providers are deploying IPv6, and support for IPv6 is
> > increasingly available in home gateway devices. While IPv6 resembles
> > IPv4 in many ways, it changes address allocation principles and allows
> > direct IP addressability and routing to devices in the home from the
> > Internet. This is a promising area in IPv6 that has proved challenging
> > in IPv4 with the proliferation of NAT.
>
> NAT devices involve two related but different issues:
> * address translation
> * an implicit "allow only return traffic" firewall-like functionality
>
> One would hope/expect that the former will be gone with IPv6. However, I
> don't think the latter will. As a result, even when you could "address"
> nodes that belong to the "home network", you probably won't be able to
> get your packets to them, unless those nodes initiated the communication
> instance.
>
> For instance (and of the top of my head), this functionality is even
> proposed in the "simple security" requirements that had been produced by
> v6ops.
>
>
> > o End-to-end communication is both an opportunity and a concern as it
> > enables new applications but also exposes nodes in the internal
> > networks to receipt of unwanted traffic from the Internet. Firewalls
> > that restrict incoming connections may be used to prevent exposure,
> > however, this reduces the efficacy of end-to-end connectivity that
> > IPv6 has the potential to restore.
>
> I personally consider this property of "end-to-end connectivity" as
> "gone". -- among other reasons, because it would require a change of
> mindset. I'm more of the idea that people will replicate the
> architecture of their IPv4 networks with IPv6, in which end-systems are
> not reachable from the public Internet.
>The opportunity for restoring e2e is one of the great opportunities of ipv6
and it is my hope this new WG will drive that with facts and take on fud.

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

Cb> Thanks!
> --
> Fernando Gont
> e-mail:  || 
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>
>
>
> _______________________________________________
> Ietf mailing list
> 
> https://www.ietf.org/mailman/listinfo/ietf

On 06/29/2011 11:38 PM, Cameron Byrne wrote:

> The opportunity for restoring e2e is one of the great opportunities of
> ipv6This assumes that e2e reachability is a desired property for all networks.> and it is my hope this new WG will drive that with facts and take
> on fud.Wasn't the simple/advanced security RFCs produced by v6ops aimed at
typical home devices?

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

On Thu, Jun 30, 2011 at 4:57 AM, Fernando Gont  wrote:
> On 06/29/2011 11:38 PM, Cameron Byrne wrote:
>
>> The opportunity for restoring e2e is one of the great opportunities of
>> ipv6
>
> This assumes that e2e reachability is a desired property for all networks.A very good point, there are a few network that break e2e on purpose.
But I guess this mostly affect enterprises and not the general
Internet part, and still I would guess that the network on the
"inside" for those enterprises still use e2e quite heavily so it's
still relevant.-- 

Roger Jorgensen           |
          | - IPv6 is The Key!
http://www.jorgensen.no   | 

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

On 29/06/11 23:18 -0300, Fernando Gont wrote:
>On 06/29/2011 05:47 AM, Jari Arkko wrote:
>[....]
>> o Service providers are deploying IPv6, and support for IPv6 is
>> increasingly available in home gateway devices. While IPv6 resembles
>> IPv4 in many ways, it changes address allocation principles and allows
>> direct IP addressability and routing to devices in the home from the
>> Internet. This is a promising area in IPv6 that has proved challenging
>> in IPv4 with the proliferation of NAT.
>
>NAT devices involve two related but different issues:
>* address translation
>* an implicit "allow only return traffic" firewall-like functionalityI'll add a 3rd component, which is application protocol mangling.

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

End-to-end communication might be better approached as the desire to
default to a configuration in which ALGs are no longer necessary, and then
address firewalling separately, which could just as well default to a no
inbound connection policy.>> o End-to-end communication is both an opportunity and a concern as it
>> enables new applications but also exposes nodes in the internal
>> networks to receipt of unwanted traffic from the Internet. Firewalls
>> that restrict incoming connections may be used to prevent exposure,
>> however, this reduces the efficacy of end-to-end connectivity that
>> IPv6 has the potential to restore.
>
>I personally consider this property of "end-to-end connectivity" as
>"gone". -- among other reasons, because it would require a change of
>mindset. I'm more of the idea that people will replicate the
>architecture of their IPv4 networks with IPv6, in which end-systems are
>not reachable from the public Internet.Home networks are bound to grow complex quite quickly. There's certainly
value in using a model that residential users are familiar with, but it
should be balanced by the inevitable need to address complexity that will
outgrow the ability of many users to manage.

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

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

On Wed, 29 Jun 2011, Fernando Gont wrote:

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

A more routed home instead of pure L2 one.> One would hope/expect that the former will be gone with IPv6. However, I 
> don't think the latter will. As a result, even when you could "address" 
> nodes that belong to the "home network", you probably won't be able to 
> get your packets to them, unless those nodes initiated the communication 
> instance.This is exactly why the whole "system" needs to work, including uPNP like 
functionality for nodes to talk to the firewall(s).> I personally consider this property of "end-to-end connectivity" as 
> "gone". -- among other reasons, because it would require a change of 
> mindset. I'm more of the idea that people will replicate the 
> architecture of their IPv4 networks with IPv6, in which end-systems are 
> not reachable from the public Internet.I think this will also change, but not for all devices from all of the 
Internet. Still, I believe there is a place for a working group to look at 
this.

I have subscribed already.-- 
Mikael Abrahamsson    email: 

On 06/30/2011 02:12 AM, Mikael Abrahamsson wrote:
>> My high level comment/question is: the proposed charter seems to
>> stress that IPv6 is the driver behind this potential wg effort...
>> however, I think that this deserves more discussion -- it's not clear
>> to me why/how typical IPv6 home networks would be much different from
>> their IPv4 counterparts.
> 
> In my mind, I see the possibility of /56 PD enabling different subnets
> for different kinds of devices with different security and functional
> needs, and also chaining of L3 devices. This definitely warrants a group
> to look at that.My point was that, except for the mechanism for PD, I don't see a
substantial difference here that would e.g. prevent this from being
developed for IPv4 (in addition to IPv6). -- Yes, I know we need to
deploy IPv6... but I don't think you can expect people to get rid of
their *working* IPv4 devices... (i.e., not sure why any of this
functionality should be v6-only)>> One would hope/expect that the former will be gone with IPv6. However,
>> I don't think the latter will. As a result, even when you could
>> "address" nodes that belong to the "home network", you probably won't
>> be able to get your packets to them, unless those nodes initiated the
>> communication instance.
> 
> This is exactly why the whole "system" needs to work, including uPNP
> like functionality for nodes to talk to the firewall(s).I think this deserves a problem statement that clearly describes what we
expect to be able to do (but currently can't), etc. And, if this is
meant to be v6-only, state why v4 is excluded -- unless we're happy to
have people connect their IPv4-devices, and see that they cannot
communicate anymore.

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

On Thu, 30 Jun 2011, Fernando Gont wrote:

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

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. 

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

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

Hi, Mark (and Jari),

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

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

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

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

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

> Thanks Mark for stating that.
> It would really be helpful if this type of text is included in the description/charter.
> The lack of of this information in the recently distributed material caused
> several immediate allergic reactions...I'm happy to include it in the next rev.

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

Mark,

100% in agreement with this stance.

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

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

JasonOn 6/30/11 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
>
>
>
>On Jun 30, 2011, at 9:25 AM, Mikael Abrahamsson wrote:
>
>> On Thu, 30 Jun 2011, Fernando Gont wrote:
>>
>>> My point was that, except for the mechanism for PD, I don't see a
>>>substantial difference here that would e.g. prevent this from being
>>>developed for IPv4 (in addition to IPv6). -- Yes, I know we need to
>>>deploy IPv6... but I don't think you can expect people to get rid of
>>>their *working* IPv4 devices... (i.e., not sure why any of this
>>>functionality should be v6-only)
>>
>> Chaining NAT boxes already work. I also feel that we shouldn't put in a
>>lot of work to develop IPv4 further, that focus should be put on IPv6.
>>
>>> I think this deserves a problem statement that clearly describes what
>>>we expect to be able to do (but currently can't), etc. And, if this is
>>>meant to be v6-only, state why v4 is excluded -- unless we're happy to
>>>have people connect their IPv4-devices, and see that they cannot
>>>communicate anymore.
>>
>> IPv4 should be excluded because it's a dead end, and we all know it.
>>We're just disagreeing when it's going to die and how.
>>
>> --
>> Mikael Abrahamsson    email: 
>> _______________________________________________
>> homegate mailing list
>> 
>> https://www.ietf.org/mailman/listinfo/homegat...
>
>_______________________________________________
>fun mailing list
>fun@ietf.org
>https://www.ietf.org/mailman/listinfo/funThis 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.

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

> Overall I like the concept of not breaking core IPv4 functionality while
> focussing all new functionality to IPv6.It is more than just IPv4 functionality... it is all the deployed
applications and devices that utilize IPv4.... and for whatever
reason, cannot be "upgraded" to IPv6. 8-)

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

On Jun 30, 2011, at 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 possibleI'd like for this group to relax the "wherever possible" bit, so as to not preclude solutions where IPv6 can do a better job than IPv4.

IPv4 is a dinosaur gasping for its last breaths.

Keith

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:  || 
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

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

> On 06/30/2011 12:46 PM, Keith Moore wrote:
>> I'd like for this group to relax the "wherever possible" bit, so as to not preclude solutions where IPv6 can do a better job than IPv4.
>> 
>> 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)I think it will be used for email and the web for at least ten years.
I think there will be a need to talk to legacy IPv4-only devices for about that long, perhaps a bit longer.
But IPv4 is already difficult to use for a great many applications, and it will only get worse with the imposition of LSN.  A home network that only supports IPv4, or which makes IPv6 as crippled as IPv4, is not a desirable goal.

Keith

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

> 
> On Jun 30, 2011, at 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
> 
> 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.


- Mark> 
> IPv4 is a dinosaur gasping for its last breaths.
> 
> Keith
> 
> 
> _______________________________________________
> homegate mailing list
> 
> https://www.ietf.org/mailman/listinfo/homegat...

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.

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

Keith

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
> 
> https://www.ietf.org/mailman/listinfo/homegat...

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

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

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

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

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

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

Cheers,
R.

On Jun 30, 2011, at 16:10 , Robert Raszuk wrote:
> 
> ...when there is new killer app which works only over v6...There's another conditional that may be more relevant.

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

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

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

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

On Jun 30, 2011, at 19:51, james woodyatt  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.

On Thu, 30 Jun 2011, Martin Focazio wrote:

> You assume at Alice CAN select a service provider. In a large part of
> the USA your choices are nil. You have a single wireline provider or
> you don't have a connection.I don't see why the IETF should spend time on IPv4 because of some 
political problem in certain countries which makes the market not work 
properly.

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

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

On Jun 30, 2011, at 6:34 PM, Martin Focazio wrote:
> On Jun 30, 2011, at 19:51, james woodyatt  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 
member of technical staff, core os networking

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

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

- Mark> 
> Cheers,
> R.
> _______________________________________________
> fun mailing list
> 
> https://www.ietf.org/mailman/listinfo/fun

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

JP Vasseur
Cisco Fellow

Sent from Blackberry

----- Original Message -----
From: Mark Townsley [mailto:]
Sent: Thursday, June 30, 2011 11:33 AM
To: Keith Moore 
Cc: IETF Discussion ;  ;  
Subject: Re: [fun] [homegate] HOMENET working group proposalOn Jun 30, 2011, at 5:46 PM, Keith Moore wrote:

> 
> On Jun 30, 2011, at 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
> 
> 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.


- Mark> 
> IPv4 is a dinosaur gasping for its last breaths.
> 
> Keith
> 
> 
> _______________________________________________
> homegate mailing list
> 
> https://www.ietf.org/mailman/listinfo/homegat..._______________________________________________
fun mailing list

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

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

Some points from the Description:> o Service providers are deploying IPv6, and support for IPv6 is
> increasingly available in home gateway devices.This is only *part* of the story.  *Users* have lots of IPv4
devices in their home.

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

> o managing routing

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

regards, kiwinOn 6/29/2011 11:51 PM, Fernando Gont wrote:
> On 06/30/2011 02:12 AM, Mikael Abrahamsson wrote:
>>> My high level comment/question is: the proposed charter seems to
>>> stress that IPv6 is the driver behind this potential wg effort...
>>> however, I think that this deserves more discussion -- it's not clear
>>> to me why/how typical IPv6 home networks would be much different from
>>> their IPv4 counterparts.
>>
>> In my mind, I see the possibility of /56 PD enabling different subnets
>> for different kinds of devices with different security and functional
>> needs, and also chaining of L3 devices. This definitely warrants a group
>> to look at that.
>
> My point was that, except for the mechanism for PD, I don't see a
> substantial difference here that would e.g. prevent this from being
> developed for IPv4 (in addition to IPv6). -- Yes, I know we need to
> deploy IPv6... but I don't think you can expect people to get rid of
> their *working* IPv4 devices... (i.e., not sure why any of this
> functionality should be v6-only)
>
>
>>> One would hope/expect that the former will be gone with IPv6. However,
>>> I don't think the latter will. As a result, even when you could
>>> "address" nodes that belong to the "home network", you probably won't
>>> be able to get your packets to them, unless those nodes initiated the
>>> communication instance.
>>
>> This is exactly why the whole "system" needs to work, including uPNP
>> like functionality for nodes to talk to the firewall(s).
>
> I think this deserves a problem statement that clearly describes what we
> expect to be able to do (but currently can't), etc. And, if this is
> meant to be v6-only, state why v4 is excluded -- unless we're happy to
> have people connect their IPv4-devices, and see that they cannot
> communicate anymore.
>
> Thanks,-- 
Stephen [kiwin] Palm   Ph.D.                          E:  
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:    
      

-----Original Message-----
From:  [mailto:] On Behalf Of Mikael Abrahamsson
Sent: 30. juni 2011 07:12
To: Fernando Gont
Cc: ; IETF Discussion
Subject: Re: [homegate] HOMENET working group proposalOn Wed, 29 Jun 2011, Fernando Gont wrote:

> This is exactly why the whole "system" needs to work, including uPNP like 
> functionality for nodes to talk to the firewall(s).UPnP like can indeed be UPnP.  The UPnP Forum has defined IPv6 firewall control as a part of UPnP now.
http://upnp.org/specs/gw/UPnP-gw-WANIPv6Firew...

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


-Erik Taraldsen

Jari,

My apologies for the tardy response, but given the following text in the proposed charter...> 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...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.

thoughts?

-ken_______________________________________________
homegate mailing list

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

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

Fred,

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

given that a lot of these boxes are linux-based, is it a case of not being implemented, or simply not being turned on in the shipped image?  And if the latter, then perhaps Homegate/Homenet offers us a means of configuring ECN/AQM.

And I agree, the algorithms would be something that is advanced in TSVWG.  And we're also in agreement that the home/SOHO/hotel segment is just one part of where bufferbloat can manifest itself.

-ken

On Jul 12, 2011, at 4:33 PM, ken carlberg wrote:

> Fred,
> 
>> 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).
> 
> given that a lot of these boxes are linux-based, is it a case of not being implemented, or simply not being turned on in the shipped image?  And if the latter, then perhaps Homegate/Homenet offers us a means of configuring ECN/AQM.Certainly, a primary homenet requirement would be that the parameters configure themselves so that a user does not have to. 

- Mark> 
> And I agree, the algorithms would be something that is advanced in TSVWG.  And we're also in agreement that the home/SOHO/hotel segment is just one part of where bufferbloat can manifest itself.
> 
> -ken
> 
> _______________________________________________
> homegate mailing list
> 
> https://www.ietf.org/mailman/listinfo/homegat...

+1 on the self-configuring of parameters

RandyOn Jul 13, 2011, at 5:07 AM, Mark Townsley  wrote:

> 
> On Jul 12, 2011, at 4:33 PM, ken carlberg wrote:
> 
>> Fred,
>> 
>>> 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).
>> 
>> given that a lot of these boxes are linux-based, is it a case of not being implemented, or simply not being turned on in the shipped image?  And if the latter, then perhaps Homegate/Homenet offers us a means of configuring ECN/AQM.
> 
> Certainly, a primary homenet requirement would be that the parameters configure themselves so that a user does not have to. 
> 
> - Mark
> 
>> 
>> And I agree, the algorithms would be something that is advanced in TSVWG.  And we're also in agreement that the home/SOHO/hotel segment is just one part of where bufferbloat can manifest itself.
>> 
>> -ken
>> 
>> _______________________________________________
>> homegate mailing list
>> 
>> https://www.ietf.org/mailman/listinfo/homegat...
> 
> _______________________________________________
> homegate mailing list
> 
> https://www.ietf.org/mailman/listinfo/homegat...
>