Subject: Re: [homegate] charter comments

From: Jason Livingood <[email-masked]>
Date: Sun, 4 Jul 2010 14:07:35 -0400

On 6/29/10 7:36 AM, "Jari Arkko" <[email-masked]> wrote:
> Rewriting to make the first sentence simpler and to remove the feeling that
> the gateway's main purpose is to provide security:
> <snip>
>> 
[JL] Your suggested change has been made.
> 
> I'm not super enthusiastic about this problem description. How about this:
> <snip>
> 
[JL] This change has been made as well.
>>  
>> A secondary problem is compatibility with and capability for the use of the
>> Internet of tomorrow. New security needs related to DNS are motivating a move
>> to DNSSEC. However, many if not most home gateways cannot handle DNSSEC,
>> which is expected to be a major problem that could significantly impede the
>> deployment of DNSSEC globally. Support for IPv6 is also lacking to a great
>> degree and there is no clear understanding of how such devices should support
>> IPv6. 
> 
> Good, but given my suggested edit above I would shorten this to:
> <snip>
> 
[JL] This change has been made as well.
>>  
>> 
>> This working group will not develop new Internet protocols, but may create
>> different requirements in the context of home gateways.
> 
> I would say: 
> <snip>
> 
[JL] This change has been made as well.
> 
> Add: The working group works together with other standards bodies (such as the
> Broadband Forum) that define requirements on home gateways. The role of the
> working group is to focus on the recommendations related to the use of
> IETF-specified technology such as DNS, NATs, or IPv6 and not overlap with
> system-level or link layer technology related specifications from these other
> standards bodies.
> 
[JL] Modified slightly to:
This working group works together with other standards development
organizations (SDOs, including groups such as the Home Gateway Initiative,
Broadband Forum, CableLabs, and others), operating outside of the IETF, that
define requirements on home gateways. The role of the working group is to
focus on the recommendations related to the use of IETF-specified technology
such as DNS, NATs, or IPv6 and not overlap with system-level or link layer
technology related specifications from these other standards bodies.
>>  
> Too handwavy and may be too detailed given that the preceding paragraphs
> should have already defined the problems.
> 
> How about this:
> <snip>
> 
[JL] Change accepted.

The updated charter now reads as follows below.  Please advise of errors and
corrections.

Proposed Charter: Broadband Internet service to homes and small offices
typically employ a "home gateway" device. This device acts as the
demarcation line between the local network and the service provider's
network. Typical implementations employ routing and/or address translation
functionality, and may involve additional capabilities such as a firewall,
wireless networking, and local services.

The basic functionality of home gateways is simple, works well, and is in
daily use by hundreds of millions of people. However, there are also
problems. These problems appear particularly with traffic types outside the
most common ones, new and upcoming Internet functionality, and under extreme
conditions. These problems include but are not limited to:

* 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 employ
TCP transport or with EDNS0. The problem is that while these complex cases
are uncommon today, they are becoming more common due 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
<http://tools.ietf.org/html/rfc4294> . 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.

The basic hypothesis of this working group is that a well organized
collection of requirements for support of various features would make it
more likely that future home gateway devices behave better in these
situations. This collection of requirements would form a single document to
document the baseline requirements derived from "core" RFCs which must be
supported. A secondary objective is to list desired-but-optional, or
"advanced", requirements from the same RFCs as well as other, non-core RFCs.
The context and reasoning behind each document which is included should be
summarized as well, in order to improve comprehension of why a given
document has been included. In most cases there are existing RFCs that
already contain the necessary requirements, such as RFC 4294
<http://tools.ietf.org/html/rfc4294> , RFC 4787
<http://tools.ietf.org/html/rfc4787> , RFC 5508
<http://tools.ietf.org/html/rfc5508> , RFC 5382
<http://tools.ietf.org/html/rfc5382> , RFC 5625
<http://tools.ietf.org/html/rfc5625> , or
RFC-to-be-draft-ietf-dnsext-dns-tcp-requirements
<http://tools.ietf.org/html/draft-ietf-dnsext-dns-tcp-requirements> . In
some other cases new requirements have to be developed.

A secondary problem is compatibility with and capability for the use of the
Internet of tomorrow. New security needs related to DNS are motivating a
move to DNSSEC. However, many if not most home gateways cannot handle
DNSSEC, which is expected to be a major problem that could significantly
impede the deployment of DNSSEC globally.

This working group will not develop new protocols, but makes recommendations
on supported features and protocols in the context of home gateways. If the
Working Group believes that new protocols are needed, it will refer the
problem to the IESG for further work in existing or new Working Groups.

This working group works together with other standards development
organizations (SDOs, including groups such as the Home Gateway Initiative,
Broadband Forum, CableLabs?
<http://trac.tools.ietf.org/area/tsv/trac/wiki/CableLabs> , and others),
operating outside of the IETF, that define requirements on home gateways.
The role of the working group is to focus on the recommendations related to
the use of IETF-specified technology such as DNS, NATs, or IPv6 and not
overlap with system-level or link layer technology related specifications
from these other standards bodies.

Proposed Deliverables and Priorities: The working group works to improve the
networking experience for the user of home gateways. The group has the
following work items:

1. Requirements document for basic, mandatory functionality for IPv4-only
home gateways (BCP)
2. Requirements document for basic, mandatory functionality for dual-stack
(IPv4 and IPv6) home gateways (BCP)
3. Requirements document for additional, optional functionality in home
gateways (BCP) 

Contributors: ISPs and home gateway developers / vendors

Who Uses the Work: Home gateway developers / vendors, ISPs

//end//

---

From: Jari Arkko <[email-masked]>
Date: Sun, 04 Jul 2010 22:40:21 +0300

Jason,

This working group works together with other standards development
organizations (SDOs, including groups such as the Home Gateway
Initiative, Broadband Forum, CableLabs, and others), operating outside
of the IETF, that define requirements on home gateways. The role of the
working group is to focus on the recommendations related to the use of
IETF-specified technology such as DNS, NATs, or IPv6 and not overlap
with system-level or link layer technology related specifications from
these other standards bodies.

OK

Jari

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 4 Jul 2010 13:07:53 -0700

This new charter wording looks good. However, it is unclear how the eventual WG will decide what is "core" and what is not. An example of this conflict appears in the charter itself: many people would say that, with the DNS root and many TLDs being signed in the coming weeks, DNSSEC is a core protocol. However, it is called "secondary" in the charter.

As we saw in the as-big-as-a-bar BoF in Stockholm, many people would say that the protocols that they work with are core to the Internet. These opinions can become even more tightly held because the charter talks about the Internet of the future, not just today's Internet.

It is good that the charter says that the eventual single document will have justification for each part of its contents; that will help make explicit the arguments that people need to make for their favorite protocols. It would be good if we could know ahead of time what criteria will be used to decide consensus (and how rough the consensus must be) on inclusion in the WG's output.

--Paul Hoffman, Director
--VPN Consortium

---

From: Jari Arkko <[email-masked]>
Date: Thu, 08 Jul 2010 15:30:58 +0300

I have been talking about this proposed working group with a number of 
different people (the IP directorate, for instance) and wanted to give a 
heads up of their feedback. Here are the issues that came up:

Should not spend any effort on IPv4. Most functions are IP version 
agnostic and it would be useful to focus on those and specifying IPv6 
behaviour.

It would also be useful to specify that home gateways should do dual 
stack. That's probably the biggest missing item right now.

People did not see much value in work item 3 (optional items).

Also, when I talked to some of my colleagues who have done work in other 
bodies around home gateways, they had a lot of trouble understanding why 
the proposed work would be useful and how it differs from past work. I 
think it is still unclear that the Homegate WG would only focus generic 
requirements on specific IETF technologies such as DNS or forwarding 
queues, not redo the addressing models or feature lists that the other 
bodies have already done.

In this context, it was also asked if there is one model for home 
gateways. There seems to be different opinions on this, and the generic 
requirements of course assume that there's at least some general 
principles that can be applied. To start with, there are routed/natted 
and bridged gateways, which are very different.

Jari

---

From: Mark Baugher <[email-masked]>
Date: Thu, 8 Jul 2010 09:12:10 -0500

On Jul 8, 2010, at 7:30 AM, Jari Arkko wrote:

> I have been talking about this proposed working group with a number of different people (the IP directorate, for instance) and wanted to give a heads up of their feedback. Here are the issues that came up:
> 
> Should not spend any effort on IPv4. Most functions are IP version agnostic and it would be useful to focus on those and specifying IPv6 behaviour.
> 
> It would also be useful to specify that home gateways should do dual stack. That's probably the biggest missing item right now.
> 
> Also, when I talked to some of my colleagues who have done work in other bodies around home gateways, they had a lot of trouble understanding why the proposed work would be useful and how it differs from past work.

Past work generally divided the home network between external and internal interfaces, above and below the transport layer, and different groups worked on different parts of the problem that are in their area of expertise.  There is a good argument, I think, for treating dual stack operation within and to and from the home network in a unified way and working on it in the IETF.

> I think it is still unclear that the Homegate WG would only focus generic requirements on specific IETF technologies such as DNS or forwarding queues, not redo the addressing models or feature lists that the other bodies have already done.
> 
> In this context, it was also asked if there is one model for home gateways. There seems to be different opinions on this, and the generic requirements of course assume that there's at least some general principles that can be applied. To start with, there are routed/natted and bridged gateways, which are very different.

If we're not going to spend time on IPv4, then we don't need to worry about natted gateways, do we?  On the other hand, if we specify home gateways should do dual stack (your second point), then we do.  I agree that the focus should be dual stack. 

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

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 8 Jul 2010 09:19:38 -0700

At 9:12 AM -0500 7/8/10, Mark Baugher wrote:
>. . .
> > . . .

I'm not sure that Jari meant "ignore IPv4"; I think he probably meant "don't do an IPv4-only profile", which is what is in the current charter proposal. I have stated my opposition to an IPv4-only profile, but certainly don't think that means that all home gateways will actually be for pure IPv6 networks.

As for Jari's differentiation between routed/natted and bridged gateways, it is probably safe to say that >99% today's home gateways are routed/natted, and therefore we need to focus on that if we want vendors to even read the eventual BCP. The section of the BCP that covers IPv6 requirements should make it clear that the IPv6 requirements *can* make the gateway a bridge instead of a router/natter.

Another thought is that the outline might be:
Intro
1. IPv4 Routing and Natting Practices
2. IPv6 Bridging and Routing Practices
...rest of sections are on layer 4 profile items...

--Paul Hoffman, Director
--VPN Consortium