Homegate charter

the current charter proposes to work on the following problems:

 * Many gateways employ simple queuing algorithms in their forwarding logic. These algorithms are simple to implement, but behave badly      under load conditions that occur commonly in home networks with, for instance, P2P or IPTV traffic. This can lead to poor response times on interactive traffic.

* Many gateways offer DNS proxying or perform firewalling that affects DNS traffic. However, while basic DNS functionality works with these designs they often fail with more complex DNS transactions, for instance when employing TCP transport or EDNS0. The problem is that while these complex cases are uncommon today, they are becoming more common for various reasons.

* Support for IPv6 is lacking to a great degree. More importantly, there is no clear understanding of what IPv6 features would be necessary on a home gateway beyond those specified in RFC 4294. For instance, what firewalling functionality should be employed, and with what defaults?

* While basic NAT functionality on outgoing TCP sessions typically works well in the gateways, they do not always support the current timeout recommendations or additional transport protocols.


I would claim that the IPv6 bullet is solved through the v6ops work. that the DNS bullet is covered largely by 5625. are we left with making a recommendation on NATs and choice of queuing algorithm? that's not something I think justifies a working group.

in contrast here is the list of problems I'd like to work on:
(this is largely the punt list from the Basic IPv6 CE router work).

1. Brave New World
   - every host is suddenly multi-homed (IPv4 and IPv6)
   - or an IPv6 only host is behind a NAT64
   - or an IPv4 host is behind NAT444
   - Happy Eyeballs

2. Service Discovery
   - Standardised service discovery in the home.

3. DNS
   - Reverse zone for delegated prefix?
   - Mechanism to delegate authority?

4. Multicast
   - Multicast routing in the home in case of a routed home
     or just MLD proxy

5. Routed home
   - Zero configuration routers / plug and play
   - Arbitrary complex topology
   - Prefix assignment
   - Distribution of other configuration information / policy
   - Unicast routing

6. IPv6 transition mechanisms
   - 6rd, DS-lite, NAT64

7. Firewall pinholing / PCP

8. Security
   - Firewall pinholing
   - End2end compliant security?
     (What's the point of IPv6 if we still break end2end with NAT44 equivalent
      security?)

9. QoS
   - Require QoS into the home, rather than just better queueing on the CPE?

cheers,
Ole

At 12:05 PM +0200 8/28/10, Ole Troan wrote:
>the current charter proposes to work on the following problems:
>
> * Many gateways employ simple queuing algorithms in their forwarding logic. These algorithms are simple to implement, but behave badly      under load conditions that occur commonly in home networks with, for instance, P2P or IPTV traffic. This can lead to poor response times on interactive traffic.
>
>* Many gateways offer DNS proxying or perform firewalling that affects DNS traffic. However, while basic DNS functionality works with these designs they often fail with more complex DNS transactions, for instance when employing TCP transport or EDNS0. The problem is that while these complex cases are uncommon today, they are becoming more common for various reasons.
>
>* Support for IPv6 is lacking to a great degree. More importantly, there is no clear understanding of what IPv6 features would be necessary on a home gateway beyond those specified in RFC 4294. For instance, what firewalling functionality should be employed, and with what defaults?
>
>* While basic NAT functionality on outgoing TCP sessions typically works well in the gateways, they do not always support the current timeout recommendations or additional transport protocols.
>
>I would claim that the IPv6 bullet is solved through the v6ops work. that the DNS bullet is covered largely by 5625. are we left with making a recommendation on NATs and choice of queuing algorithm? that's not something I think justifies a working group.However, you have listed an amalgam of RFCs instead of the one that is proposed in the charter. Do you feel that "the v6ops work" is specific enough for a home gateway vendor or purchaser to be able to determine if a particular box meets the IETF recommendations? I strongly doubt it, but you might feel differently, given your significant involvement in "the v6ops work".

I think just profiling "the v6ops work" would take a WG. Look at how much disagreement there has been even within the v6ops community on the content of those documents.>in contrast here is the list of problems I'd like to work on:
>(this is largely the punt list from the Basic IPv6 CE router work).
>
>1. Brave New World
>   - every host is suddenly multi-homed (IPv4 and IPv6)
>   - or an IPv6 only host is behind a NAT64
>   - or an IPv4 host is behind NAT444
>   - Happy EyeballsI think discussion of the first three bullets would be quite appropriate for the document coming from this WG. The fourth is also quite relevant for gateways with DNS proxies, and thus should be at least mentioned (maybe with a slightly different title...).>2. Service Discovery
>   - Standardised service discovery in the home.This doesn't seem as important to me because few gateways at the moment act as the service registry, nor prevent such discovery.>3. DNS
>   - Reverse zone for delegated prefix?
>   - Mechanism to delegate authority?Yes.>4. Multicast
>   - Multicast routing in the home in case of a routed home
>     or just MLD proxyI'm weak on this one: do home gateways participate in this? Should they?>5. Routed home
>   - Zero configuration routers / plug and play
>   - Arbitrary complex topology
>   - Prefix assignment
>   - Distribution of other configuration information / policy
>   - Unicast routingYes>6. IPv6 transition mechanisms
>   - 6rd, DS-lite, NAT64Yes>7. Firewall pinholing / PCP
>
>8. Security
>   - Firewall pinholing
>   - End2end compliant security?
>     (What's the point of IPv6 if we still break end2end with NAT44 equivalent
>      security?)Yes>9. QoS
>   - Require QoS into the home, rather than just better queueing on the CPE?Yes.

For all those yeses, however, others might disagree, and I don't think these need to be in the charter. But they are absolutely reasonable fodder for the WG's main document.

But there won't be a WG unless folks start speaking up to express interest.

--Paul Hoffman, Director
--VPN Consortium

On 8/29/2010 1:56 PM, Paul Hoffman wrote:
...
>> 2. Service Discovery
>>    - Standardised service discovery in the home.
>
> This doesn't seem as important to me because few gateways at the
> moment act as the service registry, nor prevent such discovery.
>
>> 3. DNS
>>    - Reverse zone for delegated prefix?
>>    - Mechanism to delegate authority?
>
> Yes.FWIW, #2 sometimes involves #3. Further, #3 is just a special case of 
#2. AFAICT, it's critical that this discussion involve service discovery 
issues.

Joe>> 9. QoS
>>    - Require QoS into the home, rather than just better queueing on the CPE?
>
> Yes.I didn't see "fair sharing", which is related to QoS, i.e., the 
expectation that these devices prevent a single connection from hogging 
the link (even if not congestion-controlled). That's important, IMO, to add.

Joe

Paul,>> the current charter proposes to work on the following problems:
>> 
>> * Many gateways employ simple queuing algorithms in their forwarding logic. These algorithms are simple to implement, but behave badly      under load conditions that occur commonly in home networks with, for instance, P2P or IPTV traffic. This can lead to poor response times on interactive traffic.
>> 
>> * Many gateways offer DNS proxying or perform firewalling that affects DNS traffic. However, while basic DNS functionality works with these designs they often fail with more complex DNS transactions, for instance when employing TCP transport or EDNS0. The problem is that while these complex cases are uncommon today, they are becoming more common for various reasons.
>> 
>> * Support for IPv6 is lacking to a great degree. More importantly, there is no clear understanding of what IPv6 features would be necessary on a home gateway beyond those specified in RFC 4294. For instance, what firewalling functionality should be employed, and with what defaults?
>> 
>> * While basic NAT functionality on outgoing TCP sessions typically works well in the gateways, they do not always support the current timeout recommendations or additional transport protocols.
>> 
>> I would claim that the IPv6 bullet is solved through the v6ops work. that the DNS bullet is covered largely by 5625. are we left with making a recommendation on NATs and choice of queuing algorithm? that's not something I think justifies a working group.
> 
> However, you have listed an amalgam of RFCs instead of the one that is proposed in the charter. Do you feel that "the v6ops work" is specific enough for a home gateway vendor or purchaser to be able to determine if a particular box meets the IETF recommendations? I strongly doubt it, but you might feel differently, given your significant involvement in "the v6ops work".instead of RFC4294? that is also referenced from draft-ietf-v6ops-ipv6-cpe-router.
and yes, I believe that work is specific enough.

> I think just profiling "the v6ops work" would take a WG. Look at how much disagreement there has been even within the v6ops community on the content of those documents.

I thought we agreed that "device profiles" as e.g what is done with TR-124 in the BBF isn't something we want to do in the IETF.> 
>> in contrast here is the list of problems I'd like to work on:
>> (this is largely the punt list from the Basic IPv6 CE router work).
>> 
>> 1. Brave New World
>>  - every host is suddenly multi-homed (IPv4 and IPv6)
>>  - or an IPv6 only host is behind a NAT64
>>  - or an IPv4 host is behind NAT444
>>  - Happy Eyeballs
> 
> I think discussion of the first three bullets would be quite appropriate for the document coming from this WG. The fourth is also quite relevant for gateways with DNS proxies, and thus should be at least mentioned (maybe with a slightly different title...).I think so too, and I'd rather have it mentioned in the charter.>> 2. Service Discovery
>>  - Standardised service discovery in the home.
> 
> This doesn't seem as important to me because few gateways at the moment act as the service registry, nor prevent such discovery.I would have liked the charter to state "home networks" and not be restricted to one or more border routers.>> 3. DNS
>>  - Reverse zone for delegated prefix?
>>  - Mechanism to delegate authority?
> 
> Yes.
> 
>> 4. Multicast
>>  - Multicast routing in the home in case of a routed home
>>    or just MLD proxy
> 
> I'm weak on this one: do home gateways participate in this? Should they?yes. both multicast internally in the home as well as multicast traffic from the provider. e.g IPTV.> 
>> 5. Routed home
>>  - Zero configuration routers / plug and play
>>  - Arbitrary complex topology
>>  - Prefix assignment
>>  - Distribution of other configuration information / policy
>>  - Unicast routing
> 
> Yesagree, but this needs new protocol work. which is explicitly stated in the charter that the group should not do.> 
>> 6. IPv6 transition mechanisms
>>  - 6rd, DS-lite, NAT64
> 
> Yes
> 
>> 7. Firewall pinholing / PCP
>> 
>> 8. Security
>>  - Firewall pinholing
>>  - End2end compliant security?
>>    (What's the point of IPv6 if we still break end2end with NAT44 equivalent
>>     security?)
> 
> Yes
> 
>> 9. QoS
>>  - Require QoS into the home, rather than just better queueing on the CPE?
> 
> Yes.
> 
> For all those yeses, however, others might disagree, and I don't think these need to be in the charter. But they are absolutely reasonable fodder for the WG's main document.
> 
> But there won't be a WG unless folks start speaking up to express interest.if the scope of the working group included all your yeses above, I would express interest.
right now I'm on the fence.

cheers,
Ole

At 1:21 AM +0200 8/31/10, Ole Troan wrote:
> > However, you have listed an amalgam of RFCs instead of the one that is proposed in the charter. Do you feel that "the v6ops work" is specific enough for a home gateway vendor or purchaser to be able to determine if a particular box meets the IETF recommendations? I strongly doubt it, but you might feel differently, given your significant involvement in "the v6ops work".
>
>instead of RFC4294? that is also referenced from draft-ietf-v6ops-ipv6-cpe-router.
>and yes, I believe that work is specific enough.OK, we disagree here.> > I think just profiling "the v6ops work" would take a WG. Look at how much disagreement there has been even within the v6ops community on the content of those documents.
>
>I thought we agreed that "device profiles" as e.g what is done with TR-124 in the BBF isn't something we want to do in the IETF.We didn't agree to that at all. Many people at the BoF agreed to the opposite by supporting a single profile document that could be used for "logo-izing". Of course, with no WG, that will be much harder to justify.

--Paul Hoffman, Director
--VPN Consortium

Ole,On Aug 30, 2010, at 4:21 PM, Ole Troan wrote:

> I would have liked the charter to state "home networks" and not be restricted to one or more border routers.That seems like charter creep to me since the original problem to be addressed was in the interface between the home network and the service provider network, i.e. the gateway.  Retail gateway products can be configured to run as border routers or interior routers on the home network.  So I don't see what's missing by restricting the focus to the gateway.  The term "home network" is pretty amorphous and can arguably include too much for a single WG, particularly given that the IETF has not yet standardized any home networking protocol.

Mark

On 8/31/10 2:10 AM, Mark Baugher wrote:
> Ole,
>
> On Aug 30, 2010, at 4:21 PM, Ole Troan wrote:
>
>> I would have liked the charter to state "home networks" and not be restricted to one or more border routers.
> That seems like charter creep to me since the original problem to be addressed was in the interface between the home network and the service provider network, i.e. the gateway.  Retail gateway products can be configured to run as border routers or interior routers on the home network.  So I don't see what's missing by restricting the focus to the gateway.  The term "home network" is pretty amorphous and can arguably include too much for a single WG, particularly given that the IETF has not yet standardized any home networking protocol.IIRC, there was significant interest, at least at the meeting in
Maastricht, to expand the scope of the WG to "home routing", including
not just the device at the edge of the home network and SP, but the home
network itself. This would presumably include some kind of
zero-configuration routing protocol.

Single WGs can take on rather large scope, as long as there are
participants to do the work. If the IETF scope remains "just" the home
gateway here, I personally believe the current work in the v6ops WG +
whatever targeted work items in DNSEXT and elsewhere is sufficient
without spinning up an entire WG.

- Mark> Mark
>
> _______________________________________________
> homegate mailing list
> 
> https://www.ietf.org/mailman/listinfo/homegat...

Do we really expect true routing inside the home?
Aren't we really talking about bridging and switching which is already well covered
by existing specifications, e.g. IEEE 802.1On 8/31/2010 10:28 AM, Mark Townsley wrote:
>   On 8/31/10 2:10 AM, Mark Baugher wrote:
>> Ole,
>>
>> On Aug 30, 2010, at 4:21 PM, Ole Troan wrote:
>>
>>> I would have liked the charter to state "home networks" and not be restricted to one or more border routers.
>> That seems like charter creep to me since the original problem to be addressed was in the interface between the home network and the service provider network, i.e. the gateway.  Retail gateway products can be configured to run as border routers or interior routers on the home network.  So I don't see what's missing by restricting the focus to the gateway.  The term "home network" is pretty amorphous and can arguably include too much for a single WG, particularly given that the IETF has not yet standardized any home networking protocol.
> IIRC, there was significant interest, at least at the meeting in
> Maastricht, to expand the scope of the WG to "home routing", including
> not just the device at the edge of the home network and SP, but the home
> network itself. This would presumably include some kind of
> zero-configuration routing protocol.
>
> Single WGs can take on rather large scope, as long as there are
> participants to do the work. If the IETF scope remains "just" the home
> gateway here, I personally believe the current work in the v6ops WG +
> whatever targeted work items in DNSEXT and elsewhere is sufficient
> without spinning up an entire WG.
>
> - Mark
>
>> Mark-- 
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:    
      

The UPnP Forum decided to expect true routing inside the network.  At least it is arguable that un-bridgeable networks (and applications like sensor networks) are on the horizon that might introduce the need for routing.

MarkOn Aug 31, 2010, at 11:06 AM, Stephen [kiwin] PALM wrote:

> Do we really expect true routing inside the home?
> Aren't we really talking about bridging and switching which is already well covered
> by existing specifications, e.g. IEEE 802.1
> 
> On 8/31/2010 10:28 AM, Mark Townsley wrote:
>>  On 8/31/10 2:10 AM, Mark Baugher wrote:
>>> Ole,
>>> 
>>> On Aug 30, 2010, at 4:21 PM, Ole Troan wrote:
>>> 
>>>> I would have liked the charter to state "home networks" and not be restricted to one or more border routers.
>>> That seems like charter creep to me since the original problem to be addressed was in the interface between the home network and the service provider network, i.e. the gateway.  Retail gateway products can be configured to run as border routers or interior routers on the home network.  So I don't see what's missing by restricting the focus to the gateway.  The term "home network" is pretty amorphous and can arguably include too much for a single WG, particularly given that the IETF has not yet standardized any home networking protocol.
>> IIRC, there was significant interest, at least at the meeting in
>> Maastricht, to expand the scope of the WG to "home routing", including
>> not just the device at the edge of the home network and SP, but the home
>> network itself. This would presumably include some kind of
>> zero-configuration routing protocol.
>> 
>> Single WGs can take on rather large scope, as long as there are
>> participants to do the work. If the IETF scope remains "just" the home
>> gateway here, I personally believe the current work in the v6ops WG +
>> whatever targeted work items in DNSEXT and elsewhere is sufficient
>> without spinning up an entire WG.
>> 
>> - Mark
>> 
>>> Mark
> 
> 
> -- 
> 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...

>>>
>>>I would have liked the charter to state "home networks" and not be
>>>restricted to one or more border routers.
>> That seems like charter creep to me since the original problem to be
>>addressed was in the interface between the home network and the service
>>provider network, i.e. the gateway.  Retail gateway products can be
>>configured to run as border routers or interior routers on the home
>>network.  So I don't see what's missing by restricting the focus to the
>>gateway.  The term "home network" is pretty amorphous and can arguably
>>include too much for a single WG, particularly given that the IETF has
>>not yet standardized any home networking protocol.
>IIRC, there was significant interest, at least at the meeting in
>Maastricht, to expand the scope of the WG to "home routing", including
>not just the device at the edge of the home network and SP, but the home
>network itself. This would presumably include some kind of
>zero-configuration routing protocol.That was my recollection as well -- that the effort is broader than the
home gateway device and includes how the home network accesses/interfaces
with the big "I" public Internet.>Single WGs can take on rather large scope, as long as there are
>participants to do the work. If the IETF scope remains "just" the home
>gateway here, I personally believe the current work in the v6ops WG +
>whatever targeted work items in DNSEXT and elsewhere is sufficient
>without spinning up an entire WG.Agree.

-- Jason

In practical home networks in the US and other places, people will buy a device that can function as a gateway or as an interior node on the home network depending on how they configure the WAN port.  So there is not really an debate on gateway versus routing in the charter.  I favor focusing on a device that really exists today and that forms the backbone of the home network instead of the disembodied concept of 'home routing', which may never become of practical importance to the home network.

I'm not sure what we problems we are trying to solve or what we hope to accomplish in this group.

MarkOn Aug 31, 2010, at 10:28 AM, Mark Townsley wrote:

> 
> On 8/31/10 2:10 AM, Mark Baugher wrote:
>> Ole,
>> 
>> On Aug 30, 2010, at 4:21 PM, Ole Troan wrote:
>> 
>>> I would have liked the charter to state "home networks" and not be restricted to one or more border routers.
>> That seems like charter creep to me since the original problem to be addressed was in the interface between the home network and the service provider network, i.e. the gateway.  Retail gateway products can be configured to run as border routers or interior routers on the home network.  So I don't see what's missing by restricting the focus to the gateway.  The term "home network" is pretty amorphous and can arguably include too much for a single WG, particularly given that the IETF has not yet standardized any home networking protocol.
> IIRC, there was significant interest, at least at the meeting in
> Maastricht, to expand the scope of the WG to "home routing", including
> not just the device at the edge of the home network and SP, but the home
> network itself. This would presumably include some kind of
> zero-configuration routing protocol.
> 
> Single WGs can take on rather large scope, as long as there are
> participants to do the work. If the IETF scope remains "just" the home
> gateway here, I personally believe the current work in the v6ops WG +
> whatever targeted work items in DNSEXT and elsewhere is sufficient
> without spinning up an entire WG.
> 
> - Mark
> 
>> Mark
>> 
>> _______________________________________________
>> homegate mailing list
>> 
>> https://www.ietf.org/mailman/listinfo/homegat...
> 
> _______________________________________________
> homegate mailing list
> 
> https://www.ietf.org/mailman/listinfo/homegat...

On 8/31/10 8:42 PM, Mark Baugher wrote:
> In practical home networks in the US and other places, people will
> buy a device that can function as a gateway or as an interior node on
> the home network depending on how they configure the WAN port.  So
> there is not really an debate on gateway versus routing in the
> charter.Does that port really have to be "configured", and if so by whom and in
what way?

Perhaps the WG stops short of this, that it is up to the vendor to make
it intuitive, and that the IETF makes no recommendation how to deduce
what is a WAN and what is a LAN port. Personally, I'd rather this be
more automatic and not leave it up to physical port labeling, explicit
configuration, or vendors writing code that tries to figure this out alone.> I favor focusing on a device that really exists today and
> that forms the backbone of the home network instead of the
> disembodied concept of 'home routing', which may never become of
> practical importance to the home network.I'm confused. On one hand you cite UPnP expecting home routing to exist,
along with a use-case or two backing it up. On the other you say "home
routing" may never become of practical importance.

Surely I'm missing something.> 
> I'm not sure what we problems we are trying to solve or what we hope
> to accomplish in this group.IMHO, Ole made a decent list.

- Mark> 
> Mark
> 
> On Aug 31, 2010, at 10:28 AM, Mark Townsley wrote:
> 
>> 
>> On 8/31/10 2:10 AM, Mark Baugher wrote:
>>> Ole,
>>> 
>>> On Aug 30, 2010, at 4:21 PM, Ole Troan wrote:
>>> 
>>>> I would have liked the charter to state "home networks" and not
>>>> be restricted to one or more border routers.
>>> That seems like charter creep to me since the original problem to
>>> be addressed was in the interface between the home network and
>>> the service provider network, i.e. the gateway.  Retail gateway
>>> products can be configured to run as border routers or interior
>>> routers on the home network.  So I don't see what's missing by
>>> restricting the focus to the gateway.  The term "home network" is
>>> pretty amorphous and can arguably include too much for a single
>>> WG, particularly given that the IETF has not yet standardized any
>>> home networking protocol.
>> IIRC, there was significant interest, at least at the meeting in 
>> Maastricht, to expand the scope of the WG to "home routing",
>> including not just the device at the edge of the home network and
>> SP, but the home network itself. This would presumably include some
>> kind of zero-configuration routing protocol.
>> 
>> Single WGs can take on rather large scope, as long as there are 
>> participants to do the work. If the IETF scope remains "just" the
>> home gateway here, I personally believe the current work in the
>> v6ops WG + whatever targeted work items in DNSEXT and elsewhere is
>> sufficient without spinning up an entire WG.
>> 
>> - Mark
>> 
>>> Mark
>>> 
>>> _______________________________________________ homegate mailing
>>> list  
>>> https://www.ietf.org/mailman/listinfo/homegat...
>> 
>> _______________________________________________ homegate mailing
>> list  
>> https://www.ietf.org/mailman/listinfo/homegat...
> 
> _______________________________________________ homegate mailing
> list  
> https://www.ietf.org/mailman/listinfo/homegat...
>

On Aug 31, 2010, at 3:07 PM, Mark Townsley wrote:

> 
> I'm confused. On one hand you cite UPnP expecting home routing to exist,
> along with a use-case or two backing it up. On the other you say "home
> routing" may never become of practical importance.
> 
> Surely I'm missing something.No, not necessarily.  Home networks are mostly bridged not routed today.  So why are we worried about routing?  I think you and I can agree that the present situation might change in the future.  Or it might not.  The only real evidence I have that we may need routed home networks is that one new LAN type, 802.15.4, cannot be bridged; some networks like sensor networks probably should not be bridged.  And we also expect the number of home network devices to increase exponentially in the future.  Will these factors change the status quo of having only one bridged LAN in the home?  I think it's possible but not necessarily likely.  I don't see the 'killer app' for home routing.  Multi-homing and other gateway services seem to be of more practical importance to me. But I have no crystal ball.> 
>> 
>> I'm not sure what we problems we are trying to solve or what we hope
>> to accomplish in this group.
> 
> IMHO, Ole made a decent list.
>I think it's a decent place to start if we are going to rethink the charter again. 

Mark

On 9/1/10 1:38 AM, Mark Baugher wrote:
> 
> On Aug 31, 2010, at 3:07 PM, Mark Townsley wrote:
> 
>> 
>> I'm confused. On one hand you cite UPnP expecting home routing to
>> exist, along with a use-case or two backing it up. On the other you
>> say "home routing" may never become of practical importance.
>> 
>> Surely I'm missing something.
> 
> No, not necessarily.  Home networks are mostly bridged not routed
> today.And it used to be that most home connectivity was a single PC connected
to a serial cable and modem.

I certainly don't have any hard data here, but I do remember a
presentation from Dave Thaler suggesting that the number of Teredo
connections originating from behind two levels of NAT was in the
double-digit percentages. As service provider NATs are not widely
deployed yet, the supposition is that all of these were NATs plugged
into NATs. That's not a bridged home network. And, of course, in IPv6 we
don't have the NAT to fall back on (yet, and I would rather like to
avoid it for cases where it isn't really necessary).

There is a clear trend in the US and EU of the SP providing an RG with
residential service. At the same time, various retail providers sell
hot-spots, time-machines, whatever, that act as a "networking device" of
sorts. These all end up being plugged into one another, perhaps in a
hap-hazardous fashion (but, again, perhaps less-so than a mobile ad-hoc
network which is the full-tilt extreme here).> So why are we worried about routing?  I think you and I can
> agree that the present situation might change in the future.  Or it
> might not. The only real evidence I have that we may need routed
> home networks is that one new LAN type, 802.15.4, cannot be bridged;
> some networks like sensor networks probably should not be bridged.Or, at the other end of the spectrum from a sensor network, a very high
speed media for video (or 3D video, or whatever). Or, a separate LAN for
your smartgrid.

But its not just media types, a home + guest SSID (common in a number of
RGs now) approaches the same issues of what is and is not a subnet, and
how to route, bridge or NAT between.

Or, as is the case in my home and all 4.5 million Free users, a separate
IPv6 subnet for the Free RG and video STB vs. the subnet that the home
PCs attach to (if/when the user enables IPv6 on the local LAN).> And we also expect the number of home network devices to increase
> exponentially in the future.  Will these factors change the status
> quo of having only one bridged LAN in the home?  I think it's
> possible but not necessarily likely.  I don't see the 'killer app'
> for home routing.  Multi-homing and other gateway services seem to be
> of more practical importance to me. But I have no crystal ball.No crystal ball here either. But, I know where the IETF's best play is,
and it's in IP. If bridging saves the the world and all homes can be
flat now and forever more, so be it. But in case that doesn't happen, IP
should work - and at least for IPv6, I'd rather design it than leaving
it up to chance (we left it to chance with IPv4 and the result is all
too clear).> 
>> 
>>> 
>>> I'm not sure what we problems we are trying to solve or what we
>>> hope to accomplish in this group.
>> 
>> IMHO, Ole made a decent list.
>> 
> 
> I think it's a decent place to start if we are going to rethink the
> charter again.Me too.

- Mark> 
> Mark
> 
> _______________________________________________ homegate mailing
> list  
> https://www.ietf.org/mailman/listinfo/homegat...
>

On Aug 31, 2010, at 7:38 PM, Mark Baugher wrote:

> 
> On Aug 31, 2010, at 3:07 PM, Mark Townsley wrote:
> 
>> 
>> I'm confused. On one hand you cite UPnP expecting home routing to exist,
>> along with a use-case or two backing it up. On the other you say "home
>> routing" may never become of practical importance.
>> 
>> Surely I'm missing something.
> 
> No, not necessarily.  Home networks are mostly bridged not routed today.  So why are we worried about routing?  I think you and I can agree that the present situation might change in the future.  Or it might not.  The only real evidence I have that we may need routed home networks is that one new LAN type, 802.15.4, cannot be bridged; some networks like sensor networks probably should not be bridged.  And we also expect the number of home network devices to increase exponentially in the future.  Will these factors change the status quo of having only one bridged LAN in the home?  I think it's possible but not necessarily likely.  I don't see the 'killer app' for home routing.  Multi-homing and other gateway services seem to be of more practical importance to me. But I have no crystal ball.
>The fact of the matter is that none of the devices run 802.1D bridging protocols so they are pooched if the user creates a loop anyway. Ironically, they mostly ARE capable of running RIP, at least for v4, so we are arguably closer to a practical solution with IP routing than bridging.

Therefore it seems inescapable that non-trivial home network topologies will need some kind of routing protocols. I think depending on 802.1D bridging would be the wrong way to go.

DaveO.>> 
>>> 
>>> I'm not sure what we problems we are trying to solve or what we hope
>>> to accomplish in this group.
>> 
>> IMHO, Ole made a decent list.
>> 
> 
> I think it's a decent place to start if we are going to rethink the charter again. 
> 
> Mark
> 
> _______________________________________________
> homegate mailing list
> 
> https://www.ietf.org/mailman/listinfo/homegat...

On 9/1/2010 5:54 AM, David R Oran wrote:
> The fact of the matter is that none of the devices run 802.1D bridging protocolsReally?
Which ones are you referring to?
As an example, my home network has 5+ bridges/switches and works well.

> Therefore it seems inescapable that non-trivial home network topologies will need some kind of routing protocols. I think depending on 802.1D bridging would be the wrong way to go.

Unfortunately, many of the applications that consumers run on their home networks are not tolerant
of routing... so unlikely to be accepted by consumers.

regards, kiwin-- 
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 Sep 1, 2010, at 5:54 AM, David R Oran wrote:

> 
> Therefore it seems inescapable that non-trivial home network topologies will need some kind of routing protocols. I think depending on 802.1D bridging would be the wrong way to go.HCI and compatibility issues determine to a great extent what we can and cannot introduce on the home network.  The question for me is not so much whether we need home network routing.  There is no pressing need AFAICT.  I wonder whether (or how soon) will we need non-trivial home network topologies, what applications will force this evolution, how well routing services can be be configured and run in an unmanaged environment, and what existing applications will break and how.

Mark

Mark - there is a pressing need to define how home routing should work, because - exactly as you pointed out - IEEE802.15.4 cannot be bridged.  ZigBee Alliance is defining a ZigBee-IP architecture and specification, which anticipates the use of multiple routes in the premises.  The IETF needs to specify an addressing architecture, and standards for PD and routing in the premises network, or ZA will have to do it.

- RalphOn Sep 1, 2010, at 12:26 PM, Mark Baugher  wrote:

> 
> On Sep 1, 2010, at 5:54 AM, David R Oran wrote:
> 
>> 
>> Therefore it seems inescapable that non-trivial home network topologies will need some kind of routing protocols. I think depending on 802.1D bridging would be the wrong way to go.
> 
> HCI and compatibility issues determine to a great extent what we can and cannot introduce on the home network.  The question for me is not so much whether we need home network routing.  There is no pressing need AFAICT.  I wonder whether (or how soon) will we need non-trivial home network topologies, what applications will force this evolution, how well routing services can be be configured and run in an unmanaged environment, and what existing applications will break and how.
> 
> Mark
> 
> _______________________________________________
> homegate mailing list
> 
> https://www.ietf.org/mailman/listinfo/homegat...

Let the brain dead technologies solve their own problems.
ZigBee did not even contemplate supporting IP until recently...
they should also figure out how to support bridging.
It is unreasonable for ZigBee to expect the rest of the civilized IP world change for them...
especially when there are other existing technologies that are better.

regards, kiwinOn 9/1/2010 7:03 PM, Ralph Droms wrote:
> Mark - there is a pressing need to define how home routing should work, because - exactly as you pointed out - IEEE802.15.4 cannot be bridged.  ZigBee Alliance is defining a ZigBee-IP architecture and specification, which anticipates the use of multiple routes in the premises.  The IETF needs to specify an addressing architecture, and standards for PD and routing in the premises network, or ZA will have to do it.
>
> - Ralph
>
>
>
> On Sep 1, 2010, at 12:26 PM, Mark Baugher<mbaugher@cisco.com>  wrote:
>
>>
>> On Sep 1, 2010, at 5:54 AM, David R Oran wrote:
>>
>>>
>>> Therefore it seems inescapable that non-trivial home network topologies will need some kind of routing protocols. I think depending on 802.1D bridging would be the wrong way to go.
>>
>> HCI and compatibility issues determine to a great extent what we can and cannot introduce on the home network.  The question for me is not so much whether we need home network routing.  There is no pressing need AFAICT.  I wonder whether (or how soon) will we need non-trivial home network topologies, what applications will force this evolution, how well routing services can be be configured and run in an unmanaged environment, and what existing applications will break and how.
>>
>> Mark-- 
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 Sep 2, 2010, at 9:59 AM, Stephen [kiwin] PALM wrote:

> Let the brain dead technologies solve their own problems.
> ZigBee did not even contemplate supporting IP until recently...
> they should also figure out how to support bridging.
> It is unreasonable for ZigBee to expect the rest of the civilized IP world change for them...
> especially when there are other existing technologies that are better.
>That's funny - I would see this exactly the opposite way. Rather than deal with all the problems and limitation of bridging, with all sorts of incorrect transparency assumptions, addressing mismatches, multicast inefficiencies, etc. etc., I consider it a giant step FORWARD that Zigbee saw the light and did IPv6 and will depend on IP routing to talk to the rest of the world.> regards, kiwin
> 
> On 9/1/2010 7:03 PM, Ralph Droms wrote:
>> Mark - there is a pressing need to define how home routing should work, because - exactly as you pointed out - IEEE802.15.4 cannot be bridged.  ZigBee Alliance is defining a ZigBee-IP architecture and specification, which anticipates the use of multiple routes in the premises.  The IETF needs to specify an addressing architecture, and standards for PD and routing in the premises network, or ZA will have to do it.
>> 
>> - Ralph
>> 
>> 
>> 
>> On Sep 1, 2010, at 12:26 PM, Mark Baugher<mbaugher@cisco.com>  wrote:
>> 
>>> 
>>> On Sep 1, 2010, at 5:54 AM, David R Oran wrote:
>>> 
>>>> 
>>>> Therefore it seems inescapable that non-trivial home network topologies will need some kind of routing protocols. I think depending on 802.1D bridging would be the wrong way to go.
>>> 
>>> HCI and compatibility issues determine to a great extent what we can and cannot introduce on the home network.  The question for me is not so much whether we need home network routing.  There is no pressing need AFAICT.  I wonder whether (or how soon) will we need non-trivial home network topologies, what applications will force this evolution, how well routing services can be be configured and run in an unmanaged environment, and what existing applications will break and how.
>>> 
>>> Mark
> 
> -- 
> 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...

Unfortunately legacy exists and new technologies that do not embrace legacy
usually aren't successful.
IPv6 is a classic example... it has languished since the cost and complexity of cutover
has been too high.

regards, kiwinOn 9/2/2010 7:05 AM, David R Oran wrote:
>
> On Sep 2, 2010, at 9:59 AM, Stephen [kiwin] PALM wrote:
>
>> Let the brain dead technologies solve their own problems.
>> ZigBee did not even contemplate supporting IP until recently...
>> they should also figure out how to support bridging.
>> It is unreasonable for ZigBee to expect the rest of the civilized IP world change for them...
>> especially when there are other existing technologies that are better.
>>
> That's funny - I would see this exactly the opposite way. Rather than deal with all the problems and limitation of bridging, with all sorts of incorrect transparency assumptions, addressing mismatches, multicast inefficiencies, etc. etc., I consider it a giant step FORWARD that Zigbee saw the light and did IPv6 and will depend on IP routing to talk to the rest of the world.
>
>> regards, kiwin
>>
>> On 9/1/2010 7:03 PM, Ralph Droms wrote:
>>> Mark - there is a pressing need to define how home routing should work, because - exactly as you pointed out - IEEE802.15.4 cannot be bridged.  ZigBee Alliance is defining a ZigBee-IP architecture and specification, which anticipates the use of multiple routes in the premises.  The IETF needs to specify an addressing architecture, and standards for PD and routing in the premises network, or ZA will have to do it.
>>>
>>> - Ralph
>>>
>>>
>>>
>>> On Sep 1, 2010, at 12:26 PM, Mark Baugher<mbaugher@cisco.com>   wrote:
>>>
>>>>
>>>> On Sep 1, 2010, at 5:54 AM, David R Oran wrote:
>>>>
>>>>>
>>>>> Therefore it seems inescapable that non-trivial home network topologies will need some kind of routing protocols. I think depending on 802.1D bridging would be the wrong way to go.
>>>>
>>>> HCI and compatibility issues determine to a great extent what we can and cannot introduce on the home network.  The question for me is not so much whether we need home network routing.  There is no pressing need AFAICT.  I wonder whether (or how soon) will we need non-trivial home network topologies, what applications will force this evolution, how well routing services can be be configured and run in an unmanaged environment, and what existing applications will break and how.
>>>>
>>>> Mark
>>
>> --
>> 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...
>
>-- 
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:    
      

I agree that it would be better for the IETF to address this problem than the Zigbee Alliance.Mark
On Sep 1, 2010, at 7:03 PM, Ralph Droms wrote:

> Mark - there is a pressing need to define how home routing should work, because - exactly as you pointed out - IEEE802.15.4 cannot be bridged.  ZigBee Alliance is defining a ZigBee-IP architecture and specification, which anticipates the use of multiple routes in the premises.  The IETF needs to specify an addressing architecture, and standards for PD and routing in the premises network, or ZA will have to do it.
> 
> - Ralph
> 
> 
> 
> On Sep 1, 2010, at 12:26 PM, Mark Baugher  wrote:
> 
>> 
>> On Sep 1, 2010, at 5:54 AM, David R Oran wrote:
>> 
>>> 
>>> Therefore it seems inescapable that non-trivial home network topologies will need some kind of routing protocols. I think depending on 802.1D bridging would be the wrong way to go.
>> 
>> HCI and compatibility issues determine to a great extent what we can and cannot introduce on the home network.  The question for me is not so much whether we need home network routing.  There is no pressing need AFAICT.  I wonder whether (or how soon) will we need non-trivial home network topologies, what applications will force this evolution, how well routing services can be be configured and run in an unmanaged environment, and what existing applications will break and how.
>> 
>> Mark
>> 
>> _______________________________________________
>> homegate mailing list
>> 
>> https://www.ietf.org/mailman/listinfo/homegat...

So are we back to the proposal that this group is mainly trying to find a way to make IPv6 
deployable in the real world?On 9/2/2010 7:37 AM, Mark Baugher wrote:
> I agree that it would be better for the IETF to address this problem than the Zigbee Alliance.
>
> Mark
> On Sep 1, 2010, at 7:03 PM, Ralph Droms wrote:
>
>> Mark - there is a pressing need to define how home routing should work, because - exactly as you pointed out - IEEE802.15.4 cannot be bridged.  ZigBee Alliance is defining a ZigBee-IP architecture and specification, which anticipates the use of multiple routes in the premises.  The IETF needs to specify an addressing architecture, and standards for PD and routing in the premises network, or ZA will have to do it.
>>
>> - Ralph
>>
>>
>>
>> On Sep 1, 2010, at 12:26 PM, Mark Baugher<mbaugher@cisco.com>  wrote:
>>
>>>
>>> On Sep 1, 2010, at 5:54 AM, David R Oran wrote:
>>>
>>>>
>>>> Therefore it seems inescapable that non-trivial home network topologies will need some kind of routing protocols. I think depending on 802.1D bridging would be the wrong way to go.
>>>
>>> HCI and compatibility issues determine to a great extent what we can and cannot introduce on the home network.  The question for me is not so much whether we need home network routing.  There is no pressing need AFAICT.  I wonder whether (or how soon) will we need non-trivial home network topologies, what applications will force this evolution, how well routing services can be be configured and run in an unmanaged environment, and what existing applications will break and how.
>>>
>>> Mark-- 
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 Sep 2, 2010, at 10:50 AM, Stephen [kiwin] PALM wrote:

> So are we back to the proposal that this group is mainly trying to find a way to make IPv6 deployable in the real world?
>I would say that's primarily the responsibility of v6ops. 

Homegate can (and should) refine that work as needed for the particular environment of home networks, where the OOTB experience, auto-configuration, differing defaults, simpler topologies, smaller networks, need for easy automated naming, etc. are first order considerations.> On 9/2/2010 7:37 AM, Mark Baugher wrote:
>> I agree that it would be better for the IETF to address this problem than the Zigbee Alliance.
>> 
>> Mark
>> On Sep 1, 2010, at 7:03 PM, Ralph Droms wrote:
>> 
>>> Mark - there is a pressing need to define how home routing should work, because - exactly as you pointed out - IEEE802.15.4 cannot be bridged.  ZigBee Alliance is defining a ZigBee-IP architecture and specification, which anticipates the use of multiple routes in the premises.  The IETF needs to specify an addressing architecture, and standards for PD and routing in the premises network, or ZA will have to do it.
>>> 
>>> - Ralph
>>> 
>>> 
>>> 
>>> On Sep 1, 2010, at 12:26 PM, Mark Baugher<mbaugher@cisco.com>  wrote:
>>> 
>>>> 
>>>> On Sep 1, 2010, at 5:54 AM, David R Oran wrote:
>>>> 
>>>>> 
>>>>> Therefore it seems inescapable that non-trivial home network topologies will need some kind of routing protocols. I think depending on 802.1D bridging would be the wrong way to go.
>>>> 
>>>> HCI and compatibility issues determine to a great extent what we can and cannot introduce on the home network.  The question for me is not so much whether we need home network routing.  There is no pressing need AFAICT.  I wonder whether (or how soon) will we need non-trivial home network topologies, what applications will force this evolution, how well routing services can be be configured and run in an unmanaged environment, and what existing applications will break and how.
>>>> 
>>>> Mark
> 
> -- 
> 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...

On 8/29/10 10:56 PM, Paul Hoffman wrote:
>> 2. Service Discovery
>>   - Standardised service discovery in the home.
> 
> This doesn't seem as important to me because few gateways at the moment act as the service registry, nor prevent such discovery.As most discovery mechanisms operate either fully at L2 or use multicast
DNS, gateways certainly do prevent such discovery when the home network
is divided into different multicast domains. This is of course something
that is actually quite common whenever you see more than one gateway, or
even more than one SSID (local + guest).

Also - advertising reachability for RG configuration itself would be
very convenient to have as a service, rather than relying on a numeric
address or even well-known DNS name to be typed into a web browser.

- Mark

On 8/31/2010 10:53 AM, Mark Townsley wrote:
> On 8/29/10 10:56 PM, Paul Hoffman wrote:
>>> 2. Service Discovery
>>>    - Standardised service discovery in the home.
>>
>> This doesn't seem as important to me because few gateways at the moment act as the service registry, nor prevent such discovery.
>
> As most discovery mechanisms operate either fully at L2 or use multicast
> DNS,FWIW, many use multicast but not DNS.

That doesn't change the rest of the paragraph below, but does suggest 
that DNS proxies or DNS forwarding won't resolve this issue.

Joe

  gateways certainly do prevent such discovery when the home network> is divided into different multicast domains. This is of course something
> that is actually quite common whenever you see more than one gateway, or
> even more than one SSID (local + guest).
>
> Also - advertising reachability for RG configuration itself would be
> very convenient to have as a service, rather than relying on a numeric
> address or even well-known DNS name to be typed into a web browser.
>
> - Mark
> _______________________________________________
> homegate mailing list
> 
> https://www.ietf.org/mailman/listinfo/homegat...

Ole,

I think the below contains some quite interesting possible work items.  I also agree that this list initially looks like a more compelling baseline than the current charter's contents.

I do have a couple questions/comments:

1. I'm a little unclear by what you exactly mean by service discovery in the home.  

2. What do you think needs to be specified around the transition mechanisms outside of the RFCs that define them?  Don't get me wrong -- I think that it's an important topic, but I'm just wondering what you think the additional work is.

3. Regarding in-home QoS, a numer of other organizations have done work in this area, including UPnP Forum, HGI, and DLNA.  What are you thinking here exactly?

Also, although I think much of the below list is interesting, it might be a little much to tackle all of them in a first version of a document.  I think they do span a number of different topics as well (not that the other proposed charter doesn't); there is somewhat of a risk of ending up with a charter that somewhat feels as though it could be summarized as "Miscellaneous."  I'd either work to prioritize and include the top, say, 3 things in the first document, or try to group them together from a topic perspective and choose one topic to tackle first (e.g., all topics relating to IPv6/dual stack deployment in the home network). 

Heather

________________________________________
From:  [homegate-bounces@ietf.org] On Behalf Of Ole Troan [otroan@employees.org]
Sent: Saturday, August 28, 2010 5:05 AM
To: 
Subject: [homegate] Homegate charter

the current charter proposes to work on the following problems:

 * Many gateways employ simple queuing algorithms in their forwarding logic. These algorithms are simple to implement, but behave badly      under load conditions that occur commonly in home networks with, for instance, P2P or IPTV traffic. This can lead to poor response times on interactive traffic.

* Many gateways offer DNS proxying or perform firewalling that affects DNS traffic. However, while basic DNS functionality works with these designs they often fail with more complex DNS transactions, for instance when employing TCP transport or EDNS0. The problem is that while these complex cases are uncommon today, they are becoming more common for various reasons.

* Support for IPv6 is lacking to a great degree. More importantly, there is no clear understanding of what IPv6 features would be necessary on a home gateway beyond those specified in RFC 4294. For instance, what firewalling functionality should be employed, and with what defaults?

* While basic NAT functionality on outgoing TCP sessions typically works well in the gateways, they do not always support the current timeout recommendations or additional transport protocols.


I would claim that the IPv6 bullet is solved through the v6ops work. that the DNS bullet is covered largely by 5625. are we left with making a recommendation on NATs and choice of queuing algorithm? that's not something I think justifies a working group.

in contrast here is the list of problems I'd like to work on:
(this is largely the punt list from the Basic IPv6 CE router work).

1. Brave New World
   - every host is suddenly multi-homed (IPv4 and IPv6)
   - or an IPv6 only host is behind a NAT64
   - or an IPv4 host is behind NAT444
   - Happy Eyeballs

2. Service Discovery
   - Standardised service discovery in the home.

3. DNS
   - Reverse zone for delegated prefix?
   - Mechanism to delegate authority?

4. Multicast
   - Multicast routing in the home in case of a routed home
     or just MLD proxy

5. Routed home
   - Zero configuration routers / plug and play
   - Arbitrary complex topology
   - Prefix assignment
   - Distribution of other configuration information / policy
   - Unicast routing

6. IPv6 transition mechanisms
   - 6rd, DS-lite, NAT64

7. Firewall pinholing / PCP

8. Security
   - Firewall pinholing
   - End2end compliant security?
     (What's the point of IPv6 if we still break end2end with NAT44 equivalent
      security?)

9. QoS
   - Require QoS into the home, rather than just better queueing on the CPE?

cheers,
Ole_______________________________________________
homegate mailing list

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