Subject: Re: [homegate] Minor proposed charter text update

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

On 9/1/10 4:09 AM, Andrew Sullivan wrote:
> 
> 
> On 2010-08-31, at 21:03, "David Harrington" <[email-masked]>
> wrote:
> 
>>> That is, the charter could say, "The WG will take on the topic if
>>> there is interest," without actually committing to doing that
>>> work.
>> 
>> I'm not convinced you'll get iesg to sign off on a charter like
>> that
> 
> Well, I guess I wrote a little sloppily, but the idea is to
> differentiate between the _topics_ a working group is willing to take
> on, and the specific work items a WG commits to delivering (i.e. with
> milestones). I can think of plenty of charters that seem to make this
> distinction, and there's a reason WGs occasionally have disputes
> about whether a draft is on-charter: if you had to have milestones
> for everything you could possibly do, then no such dispute would be
> possible.
> 
> I will note in my own experience that DNSEXT (to my consternation)
> has been working on this model for years.

We have 120 working groups, each with their own modus operandi. DNSEXT,
DHC, and other long-lived WGs tend to operate a bit differently than
brand new WGs, but there is no set rule.

Some WGs do exist to "attract" a home for discussion, but that doesn't
mean new work, in fact some WGs do this in order to repel new work.
e.g., "The PPPEXT working group exists to provide a forum for asking
clarifications about the existing specifications and to defend against
enhancements of questionable value."

No one WG is created equal, and that's probably a good thing.

- Mark

> A

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 1 Sep 2010 11:39:34 +0200

On 31 aug 2010, at 18:20, Ray Bellis wrote:

> The draft charter does not _propose_ any such scheme, but recognises that daisy-chained / cascaded gateways is a known existing "dual gateway" configuration[*], and thus should be addressed by the proposed WG.

> FWIW, I think that solving dual-homed networking issues is _much_ harder than getting the single gateway (or serial gateways) stuff right.

Multiple home gateways and multihoming (= multiple external connections) are orthogonal.

With multihoming, you can have one gateway that handles multiple connections. I think this is well outside the "home" realm. You can also have one gateway for each connection. This could easily happen within the home and SHOULD work. Although there are some issues here (using an address advertised by A over B) there is no immediate need for the gateways to talk to eachother, so as far as homegate is concerned there is no problem here.

The issue at hand is what happens when in the situation with n home gateways handling n external connections (with a common value for n being 1) one or more additional home gateways are deployed that connect to the existing home gateway(s) that have external connectivity:

> Is there a case for dual-homed (i.e. more than one gateway) being included now, or should that maybe form a later phase of the work?

It is very important that this is supported well because otherwise we'll see IPv4 history repeat in IPv6 and some bright entrepeneur will start selling boxes that allow you to magically share a connection. Which of course requires a port overloading NAT, which is exactly the last thing we need in IPv6.

In case anyone forgot, a few reasons why people will want to have multiple home gateways:

- the need to have multiple subnets now that more and more less trusted devices need connectivity, which should be kept far away from more trusted devices (i.e., I don't want my IP fridge to sniff my internet banking traffic)
- ISP-supplied gateways tend to be cheap and crappy, models with better features are available after market but replacing the ISP-supplied one with those may not be possible because lack of cable/DSL hardware

Without this feature, there is a different interface between ISPs and users and between anything that isn't ISP-user. This will invariably lead to problems and higher cost.

---

From: "David Harrington" <[email-masked]>
Date: Wed, 1 Sep 2010 09:33:59 -0400

Hi,

Yes, there are charters like that.
My impression is that WGs that prove they can share consensus on
what's important, and prove they can deliver on planned deliverables
in a reasonable time, get a lot of leeway when they recharter. 

I think the IESG is less likely to approve such an open-ended charter
for a brand new WG, and especially not for one where it seems
difficult to reach consensus on the overall scope of the work. 

dbh

> -----Original Message-----
> From: Andrew Sullivan [mailto:[email-masked]] 
> Sent: Tuesday, August 31, 2010 10:09 PM
> To: David Harrington
> Cc: <[email-masked]>
> Subject: Re: [homegate] Minor proposed charter text update
> 
> 
> 
> On 2010-08-31, at 21:03, "David Harrington" 
> <[email-masked]> wrote:
>  

work.
that
> differentiate between the _topics_ a working group is willing 
> to take on, and the specific work items a WG commits to 
> delivering (i.e. with milestones). I can think of plenty of 
> charters that seem to make this distinction, and there's a 
> reason WGs occasionally have disputes about whether a draft 
> is on-charter: if you had to have milestones for everything 
> you could possibly do, then no such dispute would be possible. 
> 
> I will note in my own experience that DNSEXT (to my 
> consternation) has been working on this model for years. 
> 
> A
> 
> > 
> 
> --
> Andrew Sullivan
> <[email-masked]>=

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 1 Sep 2010 10:24:33 -0400

> difficult to reach consensus on the overall scope of the work. 

Since this debate is in fact trying to reach such consensus, I guess
that's a hint from the AD that narrower is better.  Therefore, I guess
we ought to leave the broader questions out and charter only for the
narrow issues.  It'd be nice, I think, if the list moderators
explicitly declared such topics to be acceptable on this list anyway,
but I don't feel strongly about this.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Ole Troan <[email-masked]>
Date: Wed, 1 Sep 2010 16:34:52 +0200

> but I don't feel strongly about this.

it appears to be two sets of participants on this list.

- those who are happy with the existing charter
- those who are not happy with the existing charter

I belong to the second camp, but I wouldn't object to the working group being created with the current charter.

the 'problem' now seems to be that there aren't enough people stating on the list that they are volunteering to do the work. (even though I saw quite a few hands in Maastricht.)

I'm more interested in the work items I listed so I wouldn't volunteer with the current charter, but that does of course not mean that a modified charter would attract more volunteers.

does anyone have existing drafts they would like to take to this group if it was created?

cheers,
Ole

---

From: "Stephen [kiwin] PALM" <[email-masked]>
Date: Wed, 1 Sep 2010 07:42:56 -0700

On 9/1/2010 2:39 AM, Iljitsch van Beijnum wrote:
> - the need to have multiple subnets now that more and more less trusted devices need connectivity,
> which should be kept far away from more trusted devices (i.e., I don't want my IP fridge
 > to sniff my internet banking traffic)

I dont think that actually increases security... the fridge could
actually be on the network between the banking traffic generator and the gateway.
And both devices may have content to share with each other that will cause
them to have communication anyway.

-- 
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: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 1 Sep 2010 16:54:37 +0200

> them to have communication anyway.

Well, obviously we all use strong encryption so in theory sniffing is not a problem. But maybe one of these devices gets hacked and now starts collecting my friends' email addresses when I visit Facebook or whatever.

Keeping everything on a different subnet SHOULD make this type of sniffing impossible and is something that actual users may in fact understand and therefore do. Obviously there are many ways that such a strategy can still fail (sniff on the subnet between the gateways, for one).

Not sure why having packets in the same queues eventually would be a security issue, though.

All that I'm trying to say is that we can't conclude that no reasonable home user would ever want to have multiple subnets and therefore forego home gateway cascading / daisy chaining.

---

From: Ray Bellis <[email-masked]>
Date: Wed, 1 Sep 2010 15:45:49 +0000

> - those who are not happy with the existing charter

That appears correct.

> I belong to the second camp, but I wouldn't object to the working group being created with the current charter.

My recollection of the consensus in Maastricht was that it was felt that the charter was nearly ready, but not quite. 

However much of the subsequent discussion seems to be asking for much wider changes and wider scope.

Therein lies the problem.  We do not have time to reach consensus on a wider charter scope if we are to be formed as a working group before Beijing.  The cutoff date for working group session slots is just over three weeks away!

What I don't think I'm seeing are many people suggesting that the current draft charter is intrinsically flawed.  (FWIW, most of the current text came from Jari Arkko as proposed to the mailing list on June 29th).

It would be useful if we could have a straw poll of those that feel that the draft charter is broadly acceptable (or otherwise), with the understanding that as the group matures more can be added.

> the 'problem' now seems to be that there aren't enough people stating on the list that they are volunteering to do the work. (even though I saw quite a few hands in Maastricht.)

Indeed, and I took down some of their names...

> I'm more interested in the work items I listed so I wouldn't volunteer with the current charter, but that does of course not mean that a modified charter would attract more volunteers.

We have had some off-list volunteers.

I'm _sure_ you were also one of those that raised their hand in Maastricht.   [checks list, yes, you're there] ;-)

> does anyone have existing drafts they would like to take to this group if it was created?

Paul Hoffman has agreed to help start a straw-man structure as our initial work item, with content to be added later.

Ray

---

From: Etienne Gallet de Santerre <[email-masked]>
Date: Thu, 02 Sep 2010 10:32:26 +0200

All,

thanks for your answers to my question.
However, I am not sure I understand it better, so I'll try to be more 
precise.

I do not understand why we are talking about "home gateways" if they are 
in serial.
I mean, what are scenarios where there are several home gateways in 
serial (with home gateways providing routing, address translation, 
firewall, ... as defined in the charter)?
In my home network, I can easily imagine to have "routers" in serial 
(even if I find it too restrictive), but what is the point to have each 
of them providing firewall or address translation capabilities?
I need these services at the edge but not inside my network, because my 
home network is not that big.

It is still not clear to me if Homegate will deal with edge routers 
only, or with all home network routers.
In the first case, I would be happy to have an example of "cascaded home 
gateways" scenario; in the second case, why use the term "home gateway" 
instead of, for instance, "home router" or something else, which I think 
is more understandable.
In any case, I think that edge routers and internal home routers (not at 
the edge) do not have to have exactly the same functionalities, so 
require the same functionalities in both devices seems weird to me.

Regards,
Etienne

Erichsen, Kirk a écrit :
> Ray,
>
> Daisy-chained may not be helpful either. Parallel and serial are generally well understood, the "cascade" refers to several routers in serial, e.g. one behind the other. Orthogonal to this discussion of "cascaded" vs. "daisy-chained" vs. "serial" terminology, I recall a use case presented by BBF regarding multihoming (the parallel edge routers Etienne refers to below) as as either a requested inclusion into the scope, or an accepted inclusion into the scope for this phase, I don't recall which.
>
> -KE
> ________________________________________
> From: [email-masked] [[email-masked]] On Behalf Of Ray Bellis [[email-masked]]
> Sent: Tuesday, August 31, 2010 10:03 AM
> To: Etienne Gallet de Santerre
> Cc: [email-masked]
> On 31 Aug 2010, at 16:27, Etienne Gallet de Santerre wrote:
>   
>> I have some difficulties to understand the expression "home gateways may be cascaded" (maybe because English is not my natural language).
>> Does it refers to a multihomed site with several (what-I-would-call) "parallels" home gateways interconnected inside the home network?
>> Does it refers to some other devices inside the home network in addition to the one at its border?
>> Something else?
>>     
>
> A better phrase may have been "daisy chained", e.g. where the "WAN" interface of a second unit is connected to one of the "LAN" interfaces of a first unit - i.e. in series.
>
> Ray
>
> _______________________________________________
> homegate mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homegate
>
> This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
> _______________________________________________
> homegate mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homegate
>   

-- 

Cordialement, with kind regards,

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Etienne Gallet de Santerre - PhD Candidate

Institut TELECOM ; TELECOM Bretagne ; RSM Dpt

http://departements.enst-bretagne.fr/rsm/

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

From: David R Oran <[email-masked]>
Date: Thu, 2 Sep 2010 07:53:56 -0400

On Sep 2, 2010, at 4:32 AM, Etienne Gallet de Santerre wrote:

> However, I am not sure I understand it better, so I'll try to be more precise.
> 
> I do not understand why we are talking about "home gateways" if they are in serial.
> I mean, what are scenarios where there are several home gateways in serial (with home gateways providing routing, address translation, firewall, ... as defined in the charter)?
> In my home network, I can easily imagine to have "routers" in serial (even if I find it too restrictive), but what is the point to have each of them providing firewall or address translation capabilities?
Probably not each of them, but it may very well make sense to put the firewall in a different device from the one that has the access link to the provider. For example, if I have a home network with both personal and work domains (e.g. a home office), I may want to have separate firewalls with very different rules for the two. I in fact have this situation on my own home network, but I'm forced to do it using VLANS, which is painful.

In terms of address translation, the desirable state is zero, not one. 

> I need these services at the edge but not inside my network, because my home network is not that big.
> 
> It is still not clear to me if Homegate will deal with edge routers only, or with all home network routers.
Well, since the charter isn't approved, it by definition isn't clear, but my vote is to deal with all home routers, including wireless access points with multiple SSIDs subtending different subnets.

> In the first case, I would be happy to have an example of "cascaded home gateways" scenario; in the second case, why use the term "home gateway" instead of, for instance, "home router" or something else, which I think is more understandable.
As mentioned earlier in the thread, I think multi-homing, either in one box or multiple boxes, should be in scope as well. Iljitch notes that multi-homing is functional and unrelated to whether it's one box or multiple boxes, however I think the vastly more common situation is one box per ISP, because of the partitioned management and configuration questions, including finger-pointing when things break. 

> In any case, I think that edge routers and internal home routers (not at the edge) do not have to have exactly the same functionalities, so require the same functionalities in both devices seems weird to me.
> 
The requirements can easily be conditionalized in the form "if the router has a link to an ISP, then...", so I don't see this as a problem.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 2 Sep 2010 15:21:56 +0200

>> In my home network, I can easily imagine to have "routers" in serial (even if I find it too restrictive), but what is the point to have each of them providing firewall or address translation capab…

Market fragmentation. Both buyers and sellers will be much happier to deal with one type of box rather that two. Remember that we're talking about consumers here, who can barely be bothered to protect their online banking by setting up a wifi password.

> Well, since the charter isn't approved, it by definition isn't clear, but my vote is to deal with all home routers, including wireless access points with multiple SSIDs subtending different subnets.

++

Although we should be careful to only address the problems that require standardization.

> As mentioned earlier in the thread, I think multi-homing, either in one box or multiple boxes, should be in scope as well. Iljitch notes that multi-homing is functional and unrelated to whether it'…

I tried to make that point as well, a single box with connections to multiple ISPs shouldn't be part of this effort, it is too rare and too complex for that.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 2 Sep 2010 08:02:01 -0700

>I do not understand why we are talking about "home gateways" if they are in serial.

In addition to the other responses you got, I would add "because some people do that without a good reason". That is, they get "this box" from their ISP, and they see an ad for "better security for your home" and buy that box, and install it on one side or the other of the existing box, and they still get Internet connectivity, so it's all OK. This is not as uncommon as we here would all hope.

We *know* that there are some things that can go wrong with such a setup, and we can at least list them in the profile document, possibly even saying what should be done to prevent problems.

--Paul Hoffman, Director
--VPN Consortium

---

From: "David Harrington" <[email-masked]>
Date: Thu, 2 Sep 2010 11:06:05 -0400

Hi,

It's a hint from one IESG member; No decision has been made who "the
AD" will be.

My hint is that the more topics you include in the list of things to
consider, the longer it will take to reach consensus on the charter.
If you have ten topics and need to reach consensus on what you will do
with each topic, that will probably take longer than if you focus on
reaching consensus for five topics. It's a scalability issue ...

Time is rapidly running out.
We need to get a charter completed, sent to IESG for internal review,
then sent out for external review, and approved. Then we can request
WG sessions.
The cutoff for requesting a WG session is about three weeks away
(9/27).
There are two official IESG telechats before that date.
The first (9/9) could do the internal review, and request external
review.
assume two weeks for external review.
The second formal telechat (9/23) might be able to do the approval, if
there are few comment from the external review.
That allows four days from approval to session request cutoff (two
days if you don't count weekends)

But the key number is we have until 9/9 to the first telechat.
So we have one week to reach consensus, finalize the charter, and get
the internal review scheduled.

Yes, you are working on trying to achieve consensus, but I fear the
rate of convergence is rather low, given the looming deadlines.

As an IESG member, and possibly the Responsible AD, I am not impressed
by the rate of convergence so far. (I do recognize this is a difficult
problem because "home network" is so amorphous.) I would not want to
approve a charter that is open-ended because I think the WG would
spend way too much of its time debating what was or wasn't in scope.
Personally, I would much prefer a tightly-scoped charter to help keep
the WG stay focused on the deliverables. Once the WG proves it can
deliver, I would be more likely to approve a recharter that was less
tightly scoped.

But this is just a hint from one (new) IESG member. If you want to
submit an open-ended charter and see how the IESG responds, go for it.
Maybe other (more experienced) IESG members will be fine with an
open-ended charter.

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

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Andrew Sullivan
> Sent: Wednesday, September 01, 2010 10:25 AM
> To: [email-masked]
> Since this debate is in fact trying to reach such consensus, 
> I guess that's a hint from the AD that narrower is better.  
> Therefore, I guess we ought to leave the broader questions 
> out and charter only for the narrow issues.  It'd be nice, I 
> think, if the list moderators explicitly declared such topics 
> to be acceptable on this list anyway, but I don't feel 
> strongly about this.
> 
> A
> 
> --
> Andrew Sullivan
> [email-masked]
> Shinkuro, Inc.

---

From: Mark Baugher <[email-masked]>
Date: Thu, 2 Sep 2010 08:07:42 -0700

> In any case, I think that edge routers and internal home routers (not at the edge) do not have to have exactly the same functionalities, so require the same functionalities in both devices seems we…

In the US and some other geographies, most home "routers" are sold through retail channels where the customer buys the device and installs it in their home.  There is no generally no distinction made between "border routers" and "interior routers"; these names are pretty meaningless for most home users.  In general, there is one type of device that will automatically obtain a public address, set up a NAT and run DHCP or not depending on how you configure it.  Often the configuration consists of connecting the ethernet cable to a port labeled "WAN" or plugging it into one of the non-WAN labeled Ethernet ports.  Additionally, some products require that the user go into a set of configuration screens to enable or disable services.  As Mark Townsley has noted, customers routinely extend their network by plugging a new gateway/router/WiFi AP into an existing one and accidentally create another NAT'd LAN.  If installed correctly, this won't necessarily happen.  Either way, there is one device that fulfills these different roles.  It's useful to talk about the thing that is on the store shelves and actually gets plugged into a home broadband service rather than talk about some abstract device that might exist but doesn't.

IIUC, this group started as an effort to bring retail and non-retail home networking products that interface to service provider networks (i.e. gateway/routers) into conformance with standards that will allow service providers to introduce new services and provide more reliable existing services. But we have expanded this somewhat to home routing, multicast routing, inventing a third discovery service for the home, and some other tasks.

Mark

---

From: "David Harrington" <[email-masked]>
Date: Thu, 2 Sep 2010 11:14:50 -0400

Hi,

As a technical contributor who has a home network, I am not convinced
the multi-gateway/multi-router issue is the highest priority issue to
address. I think it is important, but maybe we should focus on getting
the IP infrastructure (IPv6, DHCP, DNS, NAT, FW) on each
gateway/router standardized before tackling the multi-SP integration
problem, or the cascading/serial/parallel problem. 

But that's just my opinion as a user who owns multiple
switch/router/gateways models, each of which has different features
and management user interfaces. My non-network-expert friends haven't
got a clue how to configure their devices for security or efficiency
because there are too many options, and little advice about how and
when to use those options; and if they should change models or
vendors, they get to start all over again. 

Whose "home networks" are we talking about here? IETF experts'
bleeding edge home networks, or regular users' home networks?

David Harrington 
[email-masked]

---

From: Mark Baugher <[email-masked]>
Date: Thu, 2 Sep 2010 08:33:25 -0700

> In addition to the other responses you got, I would add "because some people do that without a good reason". That is, they get "this box" from their ISP, and they see an ad for "better security for…

It's all OK as long as the only thing they do is web and email to the Internet or SP network.  But if they set up a double NAT, they lose connectivity between devices in the home.  This problem is pernicious because vendors are innovating and marketing new products, leading people to upgrade their home networks with wireless N or other services.  But these customers don't want to change out the existing gateway because it's all so mysterious.  So they plug it into the old one.  This is a case where innovation in home networking products leads to problems in the home network.

I know it's incidental to your point, but I believe that hardly anyone upgrades their home network for "better security". Over the years, I have heard of consumer questionnaires coming back where people would almost always claim that they don't care about security.  Many people who buy and install home wifi LANs apparently also claim that they don't have a home network on these questionnaires. We don't even know how to ask the right questions yet.  A couple of years ago, there was an in-depth ethnographic study conducted on home network security that started by asking the participants their views on security.  Every one of them said that they were not interested in home network security.  During the study, however, over a third of the subjects demonstrated some practice in their home that, when asked by the researcher, they claimed to be doing to avoid viruses or to protect their privacy.  Often it was something arcane like requiring guests to use a PC provided by the house rather than their own. 

Mark

---

From: "Stephen [kiwin] PALM" <[email-masked]>
Date: Thu, 2 Sep 2010 08:34:45 -0700

We absolutely must focus on "regular users' home networks".
Mark's recent post is an excellent description of what
most regular users do. From your list, I would happen to remove DNS
(since the "old" protocols work fine), but otherwise those are the
issues that are typically confronted by real users.
IPv6 isn't an issue now and if there isn't a better legacy solution
for IPv6, it never will rise to be an issue in the home LAN...
so having an a deployable IPv6 would be a "nice to have" and
the device that will or will not make it happen is the home gateway.

regards, kiwin

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 2 Sep 2010 17:41:47 +0200

> problem, or the cascading/serial/parallel problem. 

Let me repeat something Stanislav Shalunov said a few IETF meetings ago, citing Jon Postel's "Be conservative in what you send and liberal in what you except": "if you're the first implementation, be a nazi in what you accept".

When you start from scratch, you have the opportunity to get things right the first time. This is a huge advantage that shouldn't be squandered. Doing something wrong, or not doing it at all, at first means that once you get it right (as we all must eventually) you have to live with the old stuff that doesn't implement the proper way to do it. Pretty much forever. You also get the opportunity to force anyone coming after you to get things right in order to be interoperable. If the first implementation is liberal in what it accepts and the second sloppy in what it sends, then whatever comes after that will have to work around that slopiness. Again, pretty much forever.

With the cascading or whatever terminology we're going to use for this, there are two basic ways to do it, in addition to simply not doing it at all:

1. HG1 obtains a prefix from the ISP, and HG2 obtains a subprefix from HG1.

2. HG1 obtains a prefix from the ISP, and HG1 relays HG2's DHCPv6 PD request to the ISP.

2 seems to be simpler to implement here, because HG1 doesn't need to have an on-board DHCPv6 PD server implementation. Unfortunately, when HG2 gets its own prefix from the ISP, HG1 needs to set up routing towards that prefix, which means a rather involved DHCPv6 relay implementation.

So 1 isn't much worse than 2 and the fact that 2 requires cooperation from ISPs makes that we really need 1. NOT doing this will lead to all kinds of bad things:

- people refusing to upgrade to IPv6 for lack of IPv4 feature parity
- more support calls for HG vendors and ISPs
- pressure to implement IPv6 NAT

And, while all of these bad consequences are playing out, option 1 will have to be implemented anyway. So we might as well do it from the start.

As far as the wg is concerned, I don't see much of a problem, we just need a page or so that says that HGs should request a prefix using DHCPv6 PD and then run a DHCPv6 server of their own and delegate subprefixes when requested. I believe there is sufficient open source DHCPv6 server code out there, making this work is not rocket science.

> We absolutely must focus on "regular users' home networks".

Agree with that. Although we shouldn't take that to mean "anything that isn't done by 80% of all users today is out of scope".

> I would happen to remove DNS
> (since the "old" protocols work fine),

DNS proxies in HGs are notoriously buggy, which will be a big problem once DNSSEC takes off.

> IPv6 isn't an issue now

It is THE issue now. Two years or so from now there won't be any fresh IPv4 addresses anymore, while currently ISPs have a very hard time rolling out IPv6 over broadband because there is no agreed upon way for HGs and ISPs to talk IPv6 to each other.

IPv4 isn't an issue now. IPv4 over broadband is a solved problem. So if we're going to look at just one IP version it will have to be IPv6, not IPv4.

---

From: "Stephen [kiwin] PALM" <[email-masked]>
Date: Thu, 2 Sep 2010 08:56:02 -0700

> DNS proxies in HGs are notoriously buggy, which will be a big problem once DNSSEC takes off.

Home users believe DNS is buggy? (I doubt it)
Why should DNSSEC take off? Just because it was written by IETF is insufficient.

> It is THE issue now. Two years or so from now there won't be any fresh IPv4 addresses anymore, while currently ISPs have a very hard time rolling out IPv6 over broadband because there is no agreed…

You missed the point.
IPv6 is not an issue for home users now and it will never be a problem
if deploying it is a hassle to home users. Service providers and retail
router vendors will NOT do something that causes big support issues for them.

IPv4 exhaustion has been a doomsday prediction for too many decades.

SO in simple terms, IPv6 fixed to be deployable.
(otherwise it will be ignored in the home)

regards, kiwin

---

From: Joe Touch <[email-masked]>
Date: Thu, 02 Sep 2010 09:08:29 -0700

> Home users believe DNS is buggy? (I doubt it)

Home users think home routers are buggy. They often don't know why. Part 
of the reason is buggy DNS implememtations; a related reason is buggy or 
incomplete DNS configuration (lack of a reverse DNS for the public IP 
address, etc., that causes stalls in some protocols when logging or 
doing ACLs by FQDN).

> Why should DNSSEC take off? Just because it was written by IETF is

FWIW, I hope it takes off so the DNS can't so trivially be hijacked, so 
I can continue to watch YouTube videos of LOL-cats unimpeded ;-)

Joe

---

From: "Stephen [kiwin] PALM" <[email-masked]>
Date: Thu, 2 Sep 2010 09:19:25 -0700

How is an IETF WG going to improve buggy implementations?

---

From: Joe Touch <[email-masked]>
Date: Thu, 02 Sep 2010 09:21:09 -0700

> How is an IETF WG going to improve buggy implementations?

Currently there's no expectation that the implementation works, so any 
implementation is fine.

By raising awareness of the expectation that a service is necessary, it 
brings attention to the quality of the implementations.

Joe

---

From: "Stephen [kiwin] PALM" <[email-masked]>
Date: Thu, 2 Sep 2010 09:32:22 -0700

Implementers will ignore new RFCs just like they ignore old RFCs...
having an IETF therapy group wont change that.

Instead it would be much more useful for folks to put energy
into existing bodies that do certification/compliance testing of home gateways.
ie, suggesting ways to test routers better in real world situations
(including "cascaded" routers 8-) )

regards, kiwin

---

From: Ray Bellis <[email-masked]>
Date: Thu, 2 Sep 2010 16:43:46 +0000

> How is an IETF WG going to improve buggy implementations?

By getting the specialist SDOs that write requirements specifications for vendors to incorporate references to (and/or text of) IETF implementation guideline documents in those specifications.

This is exactly what has happened with RFC 5625.  The Broadband Forum's TR-124 now has a specific requirement entry just for that RFC.

-- an aside --
For what it's worth, that reference isn't quite right.

Requirement LAN.DNS.1 says:

  "The device MUST act as a DNS server ... "

and the new requirement LAN.DNS.8 says:

  "If DNS Proxy is implemented, it MUST be done according to the
   recommendations in RFC 5625".

That doesn't actually recognise that almost all home gateways actually satisfy LAN.DNS.1 by acting as a forwarding proxy, and not a full server.

Ray

---

From: Joe Touch <[email-masked]>
Date: Thu, 02 Sep 2010 09:46:46 -0700

> having an IETF therapy group wont change that.

The reason for this WG, AFAICT, is to aggregate the information needed 
to correctly implement a home gateway in a single place, and to express 
requirements that don't exist right now. Right now that information is 
scattered, hard to determine, and incomplete (is a home gateway a 
router, a host, or a NAT? not really any one of these, but some 
combination).

> into existing bodies that do certification/compliance testing of home

Home gateways currently have no requirement to implement DNS services 
correctly - that's the point, AFAICT.

Joe

---

From: "Stephen [kiwin] PALM" <[email-masked]>
Date: Thu, 2 Sep 2010 10:38:44 -0700

> correctly - that's the point, AFAICT.

Are you sure???
Vendors of said home gateways have a natural tendency to sell a product
that does not generate support calls. (support calls = lost profit).
Although that "requirement" might not be written in any RFC, it certainly
is written in any business plan.
A product that sells well and is not generating support calls is working "correctly"!
Just because a product does not implement some latest newfangled specification
does not mean it is implemented incorrectly.

So if the WG is about writing a tutorial or white paper, go for it.
We just need to make sure it is relevant to the real world implementations.

regards, kiwin

---

From: Ray Bellis <[email-masked]>
Date: Thu, 2 Sep 2010 18:53:17 +0000

> 
> Home gateways currently have no requirement to implement DNS services correctly - that's the point, AFAICT.
> 

Broadband Forum's TR-124 specifies a requirement to implement a DNS server in the gateway, but doesn't say how to do it _correctly_.

Note that I don't necessarily consider RFC 5625 a 100% definitive guide on how to do it correctly, but it does document how not to do some bits of DNS _incorrectly_, based on actual lab testing and analysis of the subsequently discovered flaws.

Ray

---

From: Ole Troan <[email-masked]>
Date: Thu, 2 Sep 2010 21:07:36 +0200

> Note that I don't necessarily consider RFC 5625 a 100% definitive guide on how to do it correctly, but it does document how not to do some bits of DNS _incorrectly_, based on actual lab testing and…

or one can make the claim that we have gotten our provisioning model wrong. which forced the DNS proxy hack.
most CPEs shouldn't have needed to have a DNS server/proxy. to paraphrase what Iljitsch said, we should try to define how a future home network should work, not focus on specifying how old hacks can be made to work better...

anyhow I'll shut up. if there is going to be a working group at all for Beijing then it appears that the current charter has as much consensus as we will be able to reach with the limited time available. 

cheers,
Ole

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 2 Sep 2010 21:19:08 +0200 (CEST)

On Thu, 2 Sep 2010, Ole Troan wrote:

> most CPEs shouldn't have needed to have a DNS server/proxy. to 
> paraphrase what Iljitsch said, we should try to define how a future home 
> network should work, not focus on specifying how old hacks can be made 
> to work better...

I think from a performance perspective, it's beneficial to have a caching 
resolver in the home, and this is most likely why there is a 
recommendation about that.

>From a functional and stability point of view, I think it's been shown 
that the CPE router manufacturers in the residential space aren't 
producing software of enough quality (and keeping it updated for a 
forseeable future) to make this work in the 5 year lifecycle of such a 
device.

I think this should be taken into account when it comes to requirements 
for such a device.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Mark Baugher <[email-masked]>
Date: Thu, 2 Sep 2010 13:39:27 -0700

On Sep 2, 2010, at 12:19 PM, Mikael Abrahamsson wrote:

> I think from a performance perspective, it's beneficial to have a caching resolver in the home, and this is most likely why there is a recommendation about that.
> 
> From a functional and stability point of view, I think it's been shown that the CPE router manufacturers in the residential space aren't producing software of enough quality (and keeping it updated for a forseeable future) to make this work in the 5 year lifecycle of such a device.

To be fair, some do it well.  In general, I too have concerns about dropping new, complex features into a class of devices that are often not well protected, have no means for field upgrades, and are buggy.

> 
> I think this should be taken into account when it comes to requirements for such a device.

So you would write a requirements document for this service that considers what is needed for it to function correctly and safely?

Mark

---

From: Martin Millnert <[email-masked]>
Date: Fri, 03 Sep 2010 01:04:09 +0200

Hi,

the three following points shout one thing out together, to me:  Put the
caching on the host. Why is it a good idea to put caches on the CPE,
where the host has no control over them and cannot purge them as part of
their "repair my internet" buttons, for example?

I especially want to learn the benefit of having a caching resolver on
the CPE, vs. the case where all connected hosts under it, has it. Heck,
on could even start out with the cases of a single host, with caching
resolver, with and without a caching CPE resolver in the middle.

Look:

On Thu, 2010-09-02 at 13:39 -0700, Mark Baugher wrote:
> > I think from a performance perspective, it's beneficial to have a
> caching resolver in the home, and this is most likely why there is a

  - Caching in the home is beneficial. No argument.  The ordinary
computer can fit large caches, btw.

> > From a functional and stability point of view, I think it's been
> shown that the CPE router manufacturers in the residential space
> aren't producing software of enough quality (and keeping it updated
> for a forseeable future) to make this work in the 5 year lifecycle of
> such a device.

  - Some OS vendors do. I would argue it is more in the interest of the
OS vendor to keep their code free from bugs, because it is something
that their customers see and use daily, than it is of a CPE vendor,
since the CPE just sits there and provides Internet, and is best left
untouched.

> To be fair, some do it well.  In general, I too have concerns about
> dropping new, complex features into a class of devices that are often
> not well protected, have no means for field upgrades, and are buggy.

Update code? OS's do that. Particularly, there is infrastructure to push
out bug fixes to millions upon millions of hosts, very quickly, today.

Why is it not enough for a CPE to just relay the configuration of its
providers DNS resolvers in its DHCP leases? To instead focus development
time, CPE silicon and money on passing the packets well, rather than
just filling the CPE with an additional network services daemon, with
its state that might very well evolve into a problem for the future
development of the internet (hard to predict the future, even if you
standardize it)

Eg: let the gateway pass packets and put the (caching) resolver on lo
(especially for DNSSEC).

Make it right. Even if the scope of this WG doesn't include what a host
SHOULD do in terms of DNS, that seems alone like a poor reason to me, to
put it on the CPE.

Cheers,
-- 
Martin Millnert <[email-masked]>

---

From: "Duncan Bees" <[email-masked]>
Date: Thu, 2 Sep 2010 10:30:49 -0700

> Instead it would be much more useful for folks to 
> put energy into existing bodies that do 
> certification/compliance testing of home gateways.
> ie, suggesting ways to test routers better in real
> world situations (including "cascaded" routers 8-) 

On the HGI home gateway test program, we are more than happy to work with
IETF on practical suggestions for needed test cases or scenarios.

The next HG test event is in late November in Hull, England.

Regarding the cascading scenarios: we are currently working on more simple
scenario: single home gateway with xDSL or Ethernet WAN, hybrid
bridge/routed connections to the LAN side, various LAN side interfaces,
bridging among LAN side.

The list of HG aspects to be tested is based on prioritisation by service
providers and vendors (both HG and chipset vendors supporting the HG) of
real-world issues. Currently includes HG performance (IPv4 and an very
initial IPv6 performance), QoS (lots of classification, queuing and
marking), multiple transport session support, software modularity support,
energy efficiency, wifi performance, VOIP, HG based storage, multi-VC
testing for xDSL.

There is no reason this type of testing cannot be extended in future to
accommodate additional aspects or protocol issues, so long as they are
relevant to the service providers and vendors deploying this gear. 

An opportunity for homegate members interested to review and comment upon
the test plan is to attend, (or observe, for non-HGI-members) the Vancouver
HGI meeting in late September. You can let me know or visit our web site for
more info.

Best regards
Duncan Bees

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Stephen [kiwin] PALM
Sent: September-02-10 9:32 AM
To: Joe Touch
Cc: [email-masked]
Subject: Re: [homegate] Minor proposed charter text update

Instead it would be much more useful for folks to put energy
into existing bodies that do certification/compliance testing of home
gateways.
ie, suggesting ways to test routers better in real world situations
(including "cascaded" routers 8-) )

regards, kiwin

---

From: Ray Bellis <[email-masked]>
Date: Thu, 2 Sep 2010 23:42:51 +0000

> providers DNS resolvers in its DHCP leases?

Because in many cases the CPE doesn't know the upstream DNS resolvers until after the LAN client has received its DHCP lease.

This can be either because the unit is disconnected from the net, or in the case of ADSL it's still in the middle of acquiring DSL sync.  In the latter case it's very common for the CPE O/S to be fully up and running before the WAN link is fully up.

[see Section 5 of RFC 5625]

Ray

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 3 Sep 2010 08:03:35 +0200 (CEST)

> computer can fit large caches, btw.

Yes, I agree, that's a better solution. Computer OS vendors are more 
likely to do this correctly than CPE router vendors (IMHO).

> since the CPE just sits there and provides Internet, and is best left 

I don't have any support on my home CPE router, even though it cost me 
over USD200 to buy. I'd imagine it's in the interest of the manufacturer 
to get me to buy a new device from them, that's how they make money. 
Putting new (or fixing) features in my old device doesn't make them any 
money.

When I tell it to be a DNS resolver/server for my home, things start to 
perform badly. I wasn't interested enough to actually try to diagnose it 
because I was sure that it wasn't worth my time to try to argue with them.

> providers DNS resolvers in its DHCP leases? To instead focus development

Yes, that's what I have set my home gateway to. It seems to do NAT just 
fine, but its dns relay is not fine.

> SHOULD do in terms of DNS, that seems alone like a poor reason to me, to 

It also makes me worry when we're talking DHCPv6-PD, running RIP in the 
home between devices etc. These are hard things to do, I've seen many try 
and fail.

---

From: Mark Baugher <[email-masked]>
Date: Mon, 6 Sep 2010 21:27:02 -0700

David,
  Multi-gateway/router issues may not be the highest priority for the
future group, but these issues are important, and we have assembled
some of the right people in this group to look at requirements
including typical home network topologies and common problems such 
as double NATs.  This probably is not the group to define home
network routing solutions, but we can and probably should
work on defining the problem.

Mark

---

From: Ralph Droms <[email-masked]>
Date: Tue, 7 Sep 2010 02:22:30 -0400

In my opinion, solutions for multiple routers and links in the home network will be needed earlier than you might think and those solutions should have pretty high priority.  They are a very real requirement for the in-home component of the "smart grid" based on 802.15.4/ZigBee-IP/SEP2.0.  ZigBee Alliance is working on requirements for "not actively managed" (quoting Dave Oran) network with multiple routers and multiple prefixes, and local naming that span multiple links.

- Ralph