Subject: On saving end-to-end transparency (was: Re: I-D.ietf-v6ops-cpe-simple-security-09)

From: Mark Townsley <[email-masked]>
Date: Mon, 22 Mar 2010 16:25:27 +0100

All,

I wish I could be in two places at once. This email will have to suffice.

A final plea before the IETF meeting slots begin.

I think that most of us on this list would agree with, at the very 
least, the ideal of end-to-end transparency with IP. Many of us are also 
realists; Realists that lived through the era of the IETF saying no to 
IPv4 NAT. Some of us may worry that we are part of a minority that will 
be overwhelmed by market forces demanding an IPv6 firewall function, 
even if we would rather not see them widely deployed.

Never fear, the market force behind an IPv6 firewall is no where near 
that of the IPv4 NAT. The benefit simply isn't anywhere near as tangible 
for the average user. The real sales pitch for IPv4 NAT was letting your 
home have multiple internet-connected PCs for the price of one. This 
benefit was pitted against end-to-end transparency, and the advantages 
of the NAT won. It is still unclear to me whether the purported 
advantages of an IPv6 firewall would outweigh the costs in terms of 
complexity and transparency, even by the mass residential market. I say 
this partly because of all of the comments saying that vendors, SDOs, 
and SPs are looking to the IETF on what to do here. This is an 
indication that the market has not yet spoken on this, otherwise no one 
would really care what recommendation we made.

It has been a long road, but it is too early to lose our ideals entirely 
here. Let's not publish a document that recommends, by default, breaking 
end-to-end transparency. If the market proves us wrong, know that we are 
not making the same fatal mistake as we did with IPv4 NAT as we are 
still defining how to create an IPv6 firewall if one so chooses.

Given that the current largest residential IPv6 deployment has no 
firewall in its CPE, and I have heard others say (on this list and 
elsewhere) that they would much rather not have to develop, deploy, and 
manage a firewalled connection, we have a real chance here to let the 
IPv6 Internet grow up without this additional complexity. I could be 
completely wrong, and the firewalls may certainly go ahead and ship on 
by default anyway. If so, what will we have lost? Nothing really, as the 
functionality of the firewall will still be there to be implemented 
against in a relatively consistent manner. However, at least it will not 
have been the IETF that shot its own principles down in the process.

Let's err on the side of our ideals here. Publish 
draft-ietf-v6ops-cpe-simple-security, but do so without default-deny 
rules on by default. Let's not break end-to-end IPv6 before it even has 
a chance to grow up.

Thanks for reading this far, and have a good IETF meeting this week. See 
you on Jabber when I can.

- Mark

---

From: Fred Baker <[email-masked]>
Date: Mon, 22 Mar 2010 08:32:38 -0700

That will have to be a working group decision. We have your opinion on the record.

On Mar 22, 2010, at 8:25 AM, Mark Townsley wrote:

> Let's err on the side of our ideals here. Publish draft-ietf-v6ops-cpe-simple-security, but do so without default-deny rules on by default. Let's not break end-to-end IPv6 before it even has a chance to grow up.

http://www.ipinc.net/IPv4.GIF

---

From: Mark Townsley <[email-masked]>
Date: Mon, 22 Mar 2010 17:01:57 +0100

> That will have to be a working group decision. We have your opinion on the record.
I'm looking for nothing more and nothing less.

- Mark

---

From: Gert Doering <[email-masked]>
Date: Mon, 22 Mar 2010 17:09:11 +0100

Hi,

> > Let's err on the side of our ideals here. Publish draft-ietf-v6ops-cpe-simple-security, but do so without default-deny rules on by default. Let's not break end-to-end IPv6 before it even has a ch…

Add another opinion to that.

 - have firewalling in there
 - default to "end-to-end communication permitted"

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  150584

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 22 Mar 2010 09:25:06 -0700

On Mon, Mar 22, 2010 at 8:25 AM, Mark Townsley <[email-masked]> wrote:
> I think that most of us on this list would agree with, at the very least,
> the ideal of end-to-end transparency with IP. Many of us are also realists;
> Realists that lived through the era of the IETF saying no to IPv4 NAT. Some
> of us may worry that we are part of a minority that will be overwhelmed by
> market forces demanding an IPv6 firewall function, even if we would rather
> not see them widely deployed.
>
> Never fear, the market force behind an IPv6 firewall is no where near that
> of the IPv4 NAT. The benefit simply isn't anywhere near as tangible for the
> average user. The real sales pitch for IPv4 NAT was letting your home have
> multiple internet-connected PCs for the price of one. This benefit was
> pitted against end-to-end transparency, and the advantages of the NAT won.
> It is still unclear to me whether the purported advantages of an IPv6
> firewall would outweigh the costs in terms of complexity and transparency,
> even by the mass residential market. I say this partly because of all of the
> comments saying that vendors, SDOs, and SPs are looking to the IETF on what
> to do here. This is an indication that the market has not yet spoken on
> this, otherwise no one would really care what recommendation we made.
>
> end-to-end transparency. If the market proves us wrong, know that we are not
> making the same fatal mistake as we did with IPv4 NAT as we are still
> defining how to create an IPv6 firewall if one so chooses.
>
> Given that the current largest residential IPv6 deployment has no firewall
> in its CPE, and I have heard others say (on this list and elsewhere) that
> they would much rather not have to develop, deploy, and manage a firewalled
> connection, we have a real chance here to let the IPv6 Internet grow up
> without this additional complexity. I could be completely wrong, and the
> firewalls may certainly go ahead and ship on by default anyway. If so, what
> will we have lost? Nothing really, as the functionality of the firewall will
> still be there to be implemented against in a relatively consistent manner.
> However, at least it will not have been the IETF that shot its own
> principles down in the process.
>
> draft-ietf-v6ops-cpe-simple-security, but do so without default-deny rules
> on by default. Let's not break end-to-end IPv6 before it even has a chance
> to grow up.

+1.  Hosts OSs have matured a lot in the last 10 years, we don't need
appliances to protect / handicap them. E2E says put the intelligence
in the host, not the network / CPE.

Cameron

>
> Thanks for reading this far, and have a good IETF meeting this week. See you
> on Jabber when I can.
>
> - Mark
>
>
>
>
>
>
>
>
>
>
>
>

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 23 Mar 2010 00:47:28 +0800

+1, too. Network may increase its intelligence as it wants. It will 
benefit the world. However, e2e transparency is still one of the most 
important features for internet infrastructure. Efforts on the network 
side should try the best to maintain it.

Sheng

于 2010/3/23 0:25, Cameron Byrne 写道:
> On Mon, Mar 22, 2010 at 8:25 AM, Mark Townsley<[email-masked]>  wrote:
>>
>> All,
>>

---

From: "STARK, BARBARA H (ATTLABS)" <[email-masked]>
Date: Mon, 22 Mar 2010 14:41:45 -0400

The real decision, IMO, is whether the IETF intends to provide an RFC
that describes *how* to do the reflective session state firewall thing
that is described in RFC 4864 Section 4.2. There really just needs to be
a decision, one way or another.

- If no, that's fine. But make that decision! And understand the
consequences: Other SDOs/documents that are referencing simple-security
will revert to a RFC 4864 Section 4.2 reference; the reflective session
state firewall will be widely implemented, but there will be little to
no consistency among those implementations.

- If yes, that's great. But make that decision, and move forward! And
don't try to play some sort of bait and switch game, like keep the
simple-security name but change it from describing a reflective session
state firewall to describing something else (like rate limiting). If the
IETF doesn't want to describe how to do reflective session state
firewalls, then kill simple-security and use a different name for
describing something different -- like easy-security.

The default discussion is irrelevant. Simple-security is being seen as a
how-to guide for doing a reflective session state IPv6 firewall.
Implementers will decide for themselves whether they want it on or off,
by default.

So, please, decide! Either let simple-security go forward, as a how-to
for a reflective session state IPv6 firewall (and nothing else), or kill
it.
Barbara

---

From: Mark Townsley <[email-masked]>
Date: Mon, 22 Mar 2010 20:38:10 +0100

For my part, I have no problem with a group of people defining how to 
build some rendition of an IPv6 firewall, as long as the reader 
understands that it is some sort of "best guess" between what IPv6 was 
designed to be and what IPv4 has become to be.

What I do have a problem with is the IETF making a recommendation that 
residential IPv6 users should sit behind such a firewall by default. 
Despite anyone's interpretation of it, RFC 4864 was not intended to make 
this kind of proclamation (I think Brian has made that substantially 
clear of late).

And, above all, that's what I am trying to clear up. Both for the 
simple-security draft, and RFC 4864.

- Mark

---

From: Antonio Querubin <[email-masked]>
Date: Tue, 23 Mar 2010 00:44:59 -1000 (HST)

On Mon, 22 Mar 2010, Mark Townsley wrote:

> draft-ietf-v6ops-cpe-simple-security, but do so without default-deny rules on 
> by default. Let's not break end-to-end IPv6 before it even has a chance to 
> grow up.

+1

Antonio Querubin
808-545-5282 x3003
e-mail/xmpp:  [email-masked]

---

From: Mohacsi Janos <[email-masked]>
Date: Tue, 23 Mar 2010 14:32:29 +0100 (CET)

> - default to "end-to-end communication permitted"

Yes to have the firewalling capabilities in CPE (reflective session state 
if you like)
Yes to be default end-to-end communication permitted - but could be 
switched to default to deny by the end users, if he or she prefers NAT 
like behaviour.

Best Regards,
 		Janos Mohacsi

---

From: Rémi Després <[email-masked]>
Date: Tue, 23 Mar 2010 08:00:36 -0700

For information: the IPv6 we have here is WITHOUT any filter (confirmed by the IETF NOC).
Does anyone report a security problem ;-) ?
RD

Le 23 mars 2010 à 06:32, Mohacsi Janos a écrit :

> Yes to have the firewalling capabilities in CPE (reflective session state if you like)
> Yes to be default end-to-end communication permitted - but could be switched to default to deny by the end users, if he or she prefers NAT like behaviour.
> 
> Best Regards,
> 		Janos Mohacsi
> 
>

---

From: Mohacsi Janos <[email-masked]>
Date: Tue, 23 Mar 2010 16:21:03 +0100 (CET)

> Does anyone report a security problem ;-) ?

Are there any possiblity to report security problems? You know, IETF folks 
are more technically competent than the average home users. They know what 
they are doing on their computers.

I think there is still some needs to hide home network devices:
- no longer supported but know to be vulnerable devices, servers
- devices without access control
- etc.

Best Regards,
 		Janos Mohacsi

>
>
> Le 23 mars 2010 ? 06:32, Mohacsi Janos a écrit :
>
>>
>>
>>

---

From: Joel Jaeggli <[email-masked]>
Date: Tue, 23 Mar 2010 08:25:23 -0700

you've got ipv4 without a filter... also there's about 2000 unmanaged
devices inside the perimeter.

---

From: Joel Jaeggli <[email-masked]>
Date: Tue, 23 Mar 2010 08:28:52 -0700

On 03/23/2010 08:21 AM, Mohacsi Janos wrote:
> Are there any possiblity to report security problems? You know, IETF
> folks are more technically competent than the average home users. They
> know what they are doing on their computers.

hah you're funny. No they don't.

>>>>>> draft-ietf-v6ops-cpe-simple-security, but do so without
>>>>>> default-deny rules on by default. Let's not break end-to-end IPv6
>>>>>> before it even has a chance to grow up.
>>>>
>>> switched to default to deny by the end users, if he or she prefers
>>> NAT like behaviour.
>>>
>>> Best Regards,
>>>         Janos Mohacsi
>>>
>>>
>>
>>
>>

---

From: Marco Hogewoning <[email-masked]>
Date: Tue, 23 Mar 2010 16:45:56 +0100

> Does anyone report a security problem ;-) ?

I guess  time will tell. After all in the old days dialin with built-in modems also worked without NAT and usually without firewalls and nobody seemed to care. Guess that with NAT acting as a firewall people got lazy and spoiled :(

From an operational perspective there is only so much you can prevent by introducing a default deny policy. From what I see and hear a lot, even most of the problems are caused by trojans downloaded by people. Then again, earlier worm outbreaks do prove it might be handy to have something in place and for us this is the main driver.

We can go all religious about end-to-end connectivity being the one true internet and trust me I work for a company that does care and exists long enough to remember what it was like. Reality with a couple of hundred thousands residentials is that we do want some form of 'nat like' behavior by default on IPv6, simply beacuse people expect it to work that way. We keep trying to convince them they should run regular updates for scanners and software, we even offer courses on it, but in practice they don't.

So for now dropping all inbound connections feels good, expecially if we want the masses to start using IPv6 fast. And yes there should be an easy button in that CPE/RG to disable that firewall and yes it should come with a BIG warning about the risks they just took.

Groet,

MarcoH

---

From: Fred Baker <[email-masked]>
Date: Tue, 23 Mar 2010 09:00:21 -0700

I'd like to bring this discussion back to a place of a little less fervor and a little more engineering, if I may. I have been staying out of it as much as anything because people really do need to be allowed to say what they think. But...

At the microphone yesterday, I had to cut the discussion off. My reasons were two-fold. One was that we were in the first discussion of several and the meeting time had to be preserved. The other was that successive speakers were saying the same thing, and spending a lot of time saying it. It had the effect of a filibuster, and I'm not in favor of filibusters as a means of getting technical work done.

It comes down to this. We as a community have two views. We would like a free and open Internet in which applications can be designed with an expectation that they can communicate amongst themselves freely. We would also like to have, and have a business need to provide for ourselves, the ability to communicate only with peer applications that have our best interests at heart. The history of humanity says that altruism is not a pervasive trait, and the history of the Internet says that we behave on the Internet the same way we do at home.

My corporate IT folks tell me they drop something on the order of 98% of the email sent to my account, because only 2% behaves in a manner consistent with good etiquette. At the firewall in front of my home I measure a 30 message per second standing load of messages from systems that I have no reason to allow into my home. For me, it comes down to the reason I have a door on my home and it is equipped with a lock. Someone who has a legitimate reason to be in my home also has the manners to knock on my door. If we don't see this on IPv6, it is for the same reason that I don't see viruses on my Mac - it's a sufficiently low value target that nobody is bothering to attack it. As soon as it becomes an interesting target, we can expect folks to attack it. The fact that it is not raining now is not proof that I will not need a roof at any time in the future. Non sequitor.

This draft was commissioned to describe a simple stateful default-deny firewall. What we decided yesterday that it would continue to describe is a simple stateful default-deny firewall. Everyone doesn't have to install one, and we decided as a group that we would have no recommendation whether they should. But for those that choose to install a simple stateful default-deny firewall, this note indicates how that should behave.

If we want to change the intent of the note, that's one thing. But we didn't yesterday decide to change the intent of the note. What we decided yesterday was to permit a second note, perhaps based on draft-vyncke-advanced-ipv6-security, that would describe an alternative security procedure. I would invite that note, and I would invite demonstration of the effectiveness of the mechanisms proposed in providing security.

Let's drop the filibuster. Please. Let's channel all this fervor into making the alternative a really good, and really honestly accurate, note.

---

From: Mark Townsley <[email-masked]>
Date: Tue, 23 Mar 2010 17:42:27 +0100

> know what they are doing on their computers.
You give us *way* more credit than we deserve :-)

- Mark

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 23 Mar 2010 18:27:27 +0100

On Tue, 23 Mar 2010 09:00:21 -0700, Fred Baker <[email-masked]> wrote:

> It comes down to this. We as a community have two views. We would like a

> free and open Internet in which applications can be designed with an

> expectation that they can communicate amongst themselves freely. We would

> also like to have, and have a business need to provide for ourselves, the

> ability to communicate only with peer applications that have our best

> interests at heart. The history of humanity says that altruism is not a

> pervasive trait, and the history of the Internet says that we behave on

the

> Internet the same way we do at home.

> My corporate IT folks tell me they drop something on the order of 98% of

> the email sent to my account,

98% of which approximately 0% are filtered by a stateful firewall.

> because only 2% behaves in a manner

> consistent with good etiquette.

> At the firewall in front of my home I

> measure a 30 message per second standing load of messages from systems

that

> I have no reason to allow into my home.

30 messages of which 0 would actually hit an open port on the target

system? (not to mention the extra entropy of IPv6 addresses) Otherwise I

would reconsider my choice of software vendors if I were you...

> For me, it comes down to the reason

> I have a door on my home and it is equipped with a lock.

But the garden in front of your house is hardly protected at all, unless

you are really rich and/or a major potential target. You'll only check the

guy's identity once he rings your door bell.

Nobody said that you should let attackers deep into your computers. The

point is, the IP stack and/or the host-local firewall is typically better

at deciding what should and shouldn't go in than the CPE. Analogies will

only get you that far.

And then that's more state to be replicated into the (cheap small) CPE than

is anyway already on the end system.

(...)

> This draft was commissioned to describe a simple stateful default-deny

> firewall. What we decided yesterday that it would continue to describe is

a

> simple stateful default-deny firewall. Everyone doesn't have to install

> one, and we decided as a group that we would have no recommendation

whether

> they should. But for those that choose to install a simple stateful

> default-deny firewall, this note indicates how that should behave.

That might be what the draft says and does not say. But lets face it.

Vendors will interpret it as IETF recommends default-deny. I just need to

check the position of most Cisco dudes here, and the job description of the

main draft author (working on Apple Airport) to make myself confident about

this.

So. I am still left wondering what the point of IPv6 is if we have

default-deny? Wouldn't it be simpler to keep IPv4 + NAT then? Three years

after this draft came up and I raised this question, I am still lingering

from an answer from the "default-deny" camp.

-- 

Rémi Denis-Courmont

http://www.remlab.net

http://fi.linkedin.com/in/remidenis

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 24 Mar 2010 06:51:08 +1300

Rémi,

Fred asked us to stop the discussion and move on. There are two
views, and the next version of the draft will make it clear, as
agreed yesterday, that this is the case. Having two views in the
IETF is not unusual.

    Brian

---

From: Rémi Després <[email-masked]>
Date: Tue, 23 Mar 2010 10:41:31 -0700

Le 23 mars 2010 à 08:45, Marco Hogewoning a écrit :

> So for now dropping all inbound connections feels good, expecially if we want the masses to start using IPv6 fast.

The fastest IPv6 deployment for masses took place 2 years ago (RFC 5569)
The main perceivable advantage of enabling IPv6, in addition to IPv4, was and still is direct inbound connectivity (used in particular with BitTorrent).
Purposely eliminating this advantage would create a legitimate reason to remain IPv4-only.

> And yes there should be an easy button in that CPE/RG to disable that firewall and yes it should come with a BIG warning about the risks they just took.

The conclusion has been in my understanding that vendors will chose which is their default mode.

Regards,
RD

---

From: james woodyatt <[email-masked]>
Date: Tue, 23 Mar 2010 11:43:01 -0700

> agreed yesterday, that this is the case. Having two views in the

I'm confident that the draft we will take to WGLC will make it clear to everyone that IETF is not making any recommendation about whether IPv6 residential gateways should or should not have Simple Security capabilities enabled in their DEFAULT modal configuration.  What it will say is that *if* a gateway has Simple Security capabilities, then here is what applications may expect those capabilities to be if our recommendations are followed by gateway vendors.

I'm quite comfortable with this outcome to our efforts.  I'll be posting the -10 revision on Friday before I return home to San Francisco.  If anyone has new technical issues to bring to the working group, then you are invited to surface them now.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: [email-masked]
Date: Wed, 24 Mar 2010 09:48:59 +0000

> This draft was commissioned to describe a simple stateful default-deny firewall. What we decided yesterday that it would continue to describe is a simple stateful default-deny firewall. Everyone do…

	if i may, if this draft was commissioned (by whom?) then it seems prudent to also
	have a draft to descrbe a simple, stateful default-accept firewall if only to provide
	a balanced choice. Otherwise we (the IETF) end up with only a single choice defined
	and after all, if there is only a single choice, what choice is there?

--bill

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 24 Mar 2010 11:49:14 +0000

On 24/03/2010 09:48, [email-masked] wrote:
> if i may, if this draft was commissioned (by whom?) then it seems
> prudent to also have a draft to descrbe a simple, stateful
> default-accept firewall if only to provide a balanced choice. Otherwise
> we (the IETF) end up with only a single choice defined and after all, if
> there is only a single choice, what choice is there?

On this basis, could I suggest you rewrite the entire body of RFCs to
include balanced choices where relevant?  E.g. we could have a BGP which by
default wouldn't exchange any prefixes unless the
PLEASE_EXCHANGE_PREFIXES_NO_REALLY capability was negotiated.  Or we have a
TCP protocol which gave the option of not being able to transfer any data
whatever (hey, don't criticise those people who don't want to transfer data
- they have a legitimate point).  We could have an MPLS which came with the
default option of forwarding tags to random next-hops, and a DNS
specification which defaulted to answering NXDOMAIN to everything.  All
balanced choices, and all as useful as providing a recommendation for
default-accept stateful CPE firewalls.

Folks, can we apply the slightest shred of common sense to this discussion?

Nick

---

From: Mark Townsley <[email-masked]>
Date: Wed, 24 Mar 2010 15:33:09 +0100

Just getting to this, Fred.

What I see is people stating their honest, technical, opinion.

It's coming out so rapidly, I believe, because there is a new 
realization by some and pent-up unspoken opinion by others that this 
document, along with the misunderstanding of RFC 4864's original intent, 
are in danger of together taking IPv6 in a way that at least a 
significant number of IETF members do not want to have their name behind.

- Mark

---

From: Fred Baker <[email-masked]>
Date: Wed, 24 Mar 2010 07:54:15 -0700

Bill:

> If we want to change the intent of the note, that's one thing. But we didn't yesterday decide to change the intent of the note. What we decided yesterday was to permit a second note, perhaps based…

That *is* a default-accept firewall.

By the way, I spoke with Eric last night suggesting that he pull together people of like mind and turn the document into something that we can consider a working group draft in Maastricht this summer. The burden of proof will be on him, Mark, and whoever collaborates with them to show that the technology they describe in fact prevents attacks; we have already heard expert commentary in the working group meeting on Monday that the premise of the service is difficult to support based on present experience.

That said, this draft was accepted by the working group as a working group draft and initially posted in June 2007, and was by design a description of a stateful firewall, which is to say, a firewall that prevents unsolicited inbound traffic. There was discussion at the time from some who didn't want a firewall described, but there was not at that time *any* discussion of anything one might call a "firewall" that by default didn't stop anything.

---

From: [email-masked]
Date: Wed, 24 Mar 2010 15:22:16 +0000

> Folks, can we apply the slightest shred of common sense to this discussion?

	Nick, that is silly.  There is precident here for publishing two
	varients; e.g. ISIS and OSPF.  As Fred pointed out, there are two
	camps, one which is passionate about default-deny as a means to 
	protect the great unwashed from bad things, and the other which
	sees default-deny as a capstone to stifle inovation and advancement.

	Personally, I have tools to run an IPsec VPN through both DNS and
	HTTP, so I don't really care if the IETF decides to lockdown and
	discard any traffic not on port 53 or port 80.  GoGo DPI!!!

	But I'd rather see a wider field open for inovation and development
	than stuffing everything into HTTP or DNS.  Just my 0.02 though.
	My point being made... I repsect Freds closing of the virtual mic.

--bill

---

From: Fred Baker <[email-masked]>
Date: Wed, 24 Mar 2010 11:12:26 -0700

Two comments, Mark.

First, if you're trying to prevent the Internet from having IPv6 firewalls, you're late. That horse left the barn in 2004, with Checkpoint announcing that it was "the first to secure IPv6". Per a 2007 ICANN study "at least 30% of the 42 [firewall] vendors surveyed, had IPv6 support" (http://www.icann.org/committees/security/sac021.pdf); those vendors include at least Checkpoint, Cisco, and Juniper from a very quick search on google, and consider the list in http://www.getipv6.info/index.php/IPv6_Firewalls. I can see removing any IETF recommendation that firewalls be deployed, which we agreed to Monday. I see value is specifying what, if one chooses to implement a default-deny firewall, that means.

Second, in this discussion, I use the word "filibuster" in accordance with its dictionary definition: "an action such as a prolonged speech that obstructs progress in a legislative assembly while not technically contravening the required procedures". At the mike on Monday, we had a succession of people who lined up to comment on the draft that in essence passionately repeated each other and each individually took a long-winded approach to doing so, and in so doing prevented other opinions from being expressed and consumed the available time to discuss the comments on the draft - and there were important comments on its recommendations. On the list in the last 48 hours, consider what has happened. YTD, speaking at 10:04 AM PDT on 24 March, we have had 502 comments on the v6ops list. More than half of those have come in since 11 March, related to the agenda of this meeting and the question regarding RFC 5006 (and much of that off-topic, on the question of a proposal I expect to receive from Remi for a container for DHCP options to be carried in an RA, and which I expect to refer to 6man as 6man is chartered to handle such questions) and this question. 78, or about one in six YTD, have been on this topic, phrasing it either as a comment on the draft, a plea for end to end transparency, or this thread. The message count has been:

         1      [email-masked]
         6      [email-masked]
         1      [email-masked]
         1      [email-masked]
         3      [email-masked]
         2      [email-masked]
         1      [email-masked]
         3      [email-masked]
         1      [email-masked]
         2      [email-masked]
         7      [email-masked]
         3      [email-masked]
         2      [email-masked]
         1      [email-masked]
         3      [email-masked]
         2      [email-masked]
         1      [email-masked]
         1      [email-masked]
         2      [email-masked]
         1      [email-masked]
         1      [email-masked]
         4      [email-masked]
        19      [email-masked]
         1      [email-masked]
         4      [email-masked]
         1      [email-masked]
         4      [email-masked]

The tenor has been pretty loud from certain quarters.

I would like to distinguish between volume of mailing, both in message count and tone, and technical discourse. "I'm agin it, it disagrees with my preferred view of the world, and I will shout it down if I can" is not "honest technical opinion". If you review the discussion, I think you will find that there are some on each side of the debate, and the decision we came to Monday, to describe firewalls but make no comment recommending for or against them, and to invite an alternative solution if it passes security muster, is supported.

On Mar 24, 2010, at 7:33 AM, Mark Townsley wrote:

> It's coming out so rapidly, I believe, because there is a new realization by some and pent-up unspoken opinion by others that this document, along with the misunderstanding of RFC 4864's original intent, are in danger of together taking IPv6 in a way that at least a significant number of IETF members do not want to have their name behind.
> 
> - Mark
> 
> 
>

---

From: Mark Townsley <[email-masked]>
Date: Wed, 24 Mar 2010 19:40:41 +0100

> First, if you're trying to prevent the Internet from having IPv6 firewalls, you're late. That horse left the barn in 2004, with Checkpoint announcing that it was "the first to secure IPv6". Per a 2…
All of the data above are with respect to firewalls for IPv6-enabled 
businesses, not residential consumer networks. In my discussion, I am 
very much separating the issue of enterprise IT-managed firewalls vs. 
residential "consumer" firewalls, since the draft is only targeting 
residential or "small business" sites.

I have no problem with enterprise managed IPv6 firewalls. The assets 
being protected, the management staff operating the equipment, and the 
types of applications being run are all very different than the typical 
residential site. There is some overlap, for telecommuting workers such 
as yourself, but by and large these are very different use-cases. The 
v6ops draft is *not* targeting enterprise firewalls at all. If it was, 
we wouldn't be agonizing over well-defined defaults, for one.

> I would like to distinguish between volume of mailing, both in message count and tone, and technical discourse. "I'm agin it, it disagrees with my preferred view of the world, and I will shout it d…
Then consider much of the discussion as a prelude to what kind of 
alternative solution we need. If we are to have an alternative, those 
that do not agree with the current status quo need to be able to state why.

On "filibustering" and the number of messages you are seeing from me, I 
suppose you are seeing what happens on email when I don't get a chance 
to speak at the mic in person. Apologies, it doesn't happen often.

- Mark

---

From: Fred Baker <[email-masked]>
Date: Wed, 24 Mar 2010 11:45:24 -0700

On Mar 24, 2010, at 11:40 AM, Mark Townsley wrote:

> Then consider much of the discussion as a prelude to what kind of alternative solution we need. If we are to have an alternative, those that do not agree with the current status quo need to be able to state why.

As I said a couple of messages back, I suggested to Eric last night that he collect a group of like-minded individuals and describe that alternative. Yes, I would expect that the proposal would contain discussion of the philosophy behind it. I suspect that your+his draft is a start at that, although I won't hold you (collectively) to it, and I would suggest an early security directorate review.

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 25 Mar 2010 21:47:41 +0000

> 	My point being made... I repsect Freds closing of the virtual mic.

likewise, I apologise to all for shouting so loudly about what the colour
of the bikeshed ought to be.

Nick
/relurk