Subject: [homegate] Homegate charter

From: Ole Troan <[email-masked]>
Date: Sat, 28 Aug 2010 12:05:56 +0200

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

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 29 Aug 2010 13:56:20 -0700

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

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.

>   - or an IPv4 host is behind NAT444

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

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

>   - Mechanism to delegate authority?

Yes.

>   - Multicast routing in the home in case of a routed home

I'm weak on this one: do home gateways participate in this? Should they?

>   - Distribution of other configuration information / policy

Yes

>6. IPv6 transition mechanisms

Yes

>     (What's the point of IPv6 if we still break end2end with NAT44 equivalent

Yes

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

---

From: Joe Touch <[email-masked]>
Date: Mon, 30 Aug 2010 15:23:01 -0700

On 8/29/2010 1:56 PM, Paul Hoffman wrote:
...
> 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

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

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

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

---

From: Ole Troan <[email-masked]>
Date: Tue, 31 Aug 2010 01:21:33 +0200

Paul,

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

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.

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

I think so too, and I'd rather have it mentioned in the charter.

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

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

>>  - Distribution of other configuration information / policy

agree, but this needs new protocol work. which is explicitly stated in the charter that the group should not do.

> 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

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 30 Aug 2010 16:52:00 -0700

>and yes, I believe that work is specific enough.

OK, we disagree here.

>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

---

From: Mark Baugher <[email-masked]>
Date: Mon, 30 Aug 2010 17:10:25 -0700

Ole,

> 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

---

From: Mark Townsley <[email-masked]>
Date: Tue, 31 Aug 2010 19:28:27 +0200

> 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 prod…
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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homegate

---

From: Mark Townsley <[email-masked]>
Date: Tue, 31 Aug 2010 19:53:14 +0200

> 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

---

From: "Stephen [kiwin] PALM" <[email-masked]>
Date: Tue, 31 Aug 2010 11:06:49 -0700

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

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

---

From: Joe Touch <[email-masked]>
Date: Tue, 31 Aug 2010 11:21:01 -0700

On 8/31/2010 10:53 AM, Mark Townsley wrote:
> 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

---

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 31 Aug 2010 18:25:24 +0000

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

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.

>without spinning up an entire WG.

Agree.

-- Jason

---

From: Mark Baugher <[email-masked]>
Date: Tue, 31 Aug 2010 11:26:45 -0700

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.

Mark

---

From: Mark Baugher <[email-masked]>
Date: Tue, 31 Aug 2010 11:42:27 -0700

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.

Mark

---

From: Mark Townsley <[email-masked]>
Date: Wed, 01 Sep 2010 00:07:09 +0200

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.

> to accomplish in this group.

IMHO, Ole made a decent list.

- Mark

>>>> 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.
>> 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.
>> 
>> 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 [email-masked] 
>> _______________________________________________ homegate mailing
>> list [email-masked] 
> _______________________________________________ homegate mailing
> list [email-masked]

---

From: Mark Baugher <[email-masked]>
Date: Tue, 31 Aug 2010 16:38:34 -0700

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

> 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

---

From: "Kirksey, Heather R (Heather)" <[email-masked]>
Date: Tue, 31 Aug 2010 18:42:23 -0500

Mark,

I also think that it could be a good idea to have the charter reference home networks rather than simply the home border routers, depending on what exactly you end up specifying in this area (note that I haven't responded to Ole's mail yet but will shortly although I think it does provide a good starting point).  I think this is an area where the IETF could add some real value, especially in the area of IPv6 deployment in the home, and it reduces the possbility of overlap with other organizations. 

Regarding scope size: on the one hand, yes, this could potentially widen the scope because it's opening the door to talk about more than one device, but on the other I think it actually could better focus the work.

Thanks,
Heather

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Livingood, Jason [[email-masked]]
Sent: Tuesday, August 31, 2010 1:25 PM
To: Mark Townsley; [email-masked]
Subject: Re: [homegate] Homegate charter

Agree.

-- Jason

---

From: "Kirksey, Heather R (Heather)" <[email-masked]>
Date: Tue, 31 Aug 2010 19:38:55 -0500

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: [email-masked] [[email-masked]] On Behalf Of Ole Troan [[email-masked]]
Sent: Saturday, August 28, 2010 5:05 AM
To: [email-masked]
Subject: [homegate] Homegate charter

1. Brave New World

2. Service Discovery

3. DNS

4. Multicast

5. Routed home

8. Security
   - Firewall pinholing

9. QoS

cheers,
Ole

---

From: Mark Townsley <[email-masked]>
Date: Wed, 01 Sep 2010 02:59:13 +0200

On 9/1/10 1:38 AM, Mark Baugher 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.
>> 
> 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 think it's a decent place to start if we are going to rethink the

Me too.

- Mark