IPv6 Firewall on CPEs - Default on or off

Benedikt Stockebrand me at benedikt-stockebrand.de
Mon Nov 26 12:04:23 CET 2012

Hi Ragnar and list,

First of all: I assume that your CPEs are managed by your customers
themselves, not by you.  If you manage them centrally, the situation
is slightly different, though the end result is pretty much the same.

And a side note: The main problem with end to end connectivity is the
fact that the majority of consumer ISPs go for dynamic address
assignments, not a packet filter/firewall that needs to be told to
open a port for access from the outside whenever actually desired.

"Anfinsen, Ragnar" <Ragnar.Anfinsen at altibox.no> writes:

> However, our marketing guys have now started to question whether the
> IPv6 firewall function should be on or off by default. 
> [...]
> I have my personal and clear opinion about the matter, which is
> off. To be able to uphold the true end to end connectivity it must
> obviously be off. I think the application firewall on the new OS's
> that support IPv6 are more than good enough, and a firewall in the
> CPE is redundant.

If all between your customer's system and the Internet is a "personal
firewall" that is easy to turn off by accident, or during
troubleshooting, or for gaming, then you *want* that redundancy.

And a question rather than a statement: If I configure a Vista++
system to run in a "trusted network"/"home network" or whatever, will
it then assume to be protected by a "diode-style" CPE configuration?
If so, then setting the CPE default to "open both ways" is asking for
massive trouble.

What about devices that don't come with a "personal firewall"?  I
know people who use a network printer at home simply because that
allows to make it accessible to everyone in the household.  The same
applies to SIP phones and such.

> However, the arguments against is that the customer is used to
> having a security layer on IPv4 in the CPE (NAT), and it would be
> bad to allow IPv6 unprotected into the customers LAN.

That's the major point.  Basically, if you provide some new
security-sensitive feature to your customers, you should *never* do so
without making sure that they know and understand about it.  And that
is easiest done by setting the defaults so they have to consciously
enable it.

It's the same as with Teredo on Vista++: As a tunnel mechanism itself
it is quite useful (as a last resort, and anyone trying to start a
discussion on that please open another thread), but enabling it by
default has already caused significant trouble to some people.
Allowing customers to make whatever devices on the "inside" accessible
from the "outside" is a valuable extra, but allowing so by default
should and will be considered highly irresponsible.

What may be even worse, it'll likely give IPv6 the same kind of bad
press that Teredo already did, slowing down the global deployment even

And to make things really ugly this even has a legal dimension to it:
If any of your customers is getting attacked via IPv6 then you might
actually be held liable for the damages---because you didn't take care
of the risks of that new technology that "you forced upon them".
Maybe you should talk to some layers about their opinion---and a few
random judges, to get an idea of how far you can expect to get a
reasonable court decision if any of your customers sues you:-(



PS: Maybe some time some CPE vendor has both the brains and guts to
    build gear that has two "internal" interfaces---a "red" one that
    is open to access from the "outside" and a "green" one that only
    allows access from the "inside" to the "outside".  But that won't
    help you right now.

			 Business Grade IPv6
		    Consulting, Training, Projects

Benedikt Stockebrand, Dipl.-Inform.   http://www.benedikt-stockebrand.de/

More information about the ipv6-ops mailing list