A challenge (was Re: Default security functions on an IPv6 CPE)

Mark Smith nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org
Fri May 20 17:55:09 CEST 2011

On Fri, 20 May 2011 17:31:18 +0200
"S.P.Zeidler" <spz at serpens.de> wrote:

> Thus wrote Mark Smith (nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org):
> > Just make sure you don't get in the way of what your customers are
> > trying to achieve with their Internet connection.
> I think noone proposed to put filter rules on a device that could not be
> changed. All we are discussing is a sane initial config.

A default the customer isn't expecting, and that an application has to
work around to succeed in communicating is not a sane initial config.

Customers just expect the applications they install on their
end-nodes. If SPs put barriers in place to stop that, application
developers will actively spend time on working around those barriers.

Think about all the time that has been spent on NAT traversal. Imagine
if, instead, that time had been spent on application "things" rather
than working around constraints in the network layer. Today we'd
then have better applications or new applications, rather than ones
that have the added cost and complexity overheads of working around
NAT constraints.

Networked application developers have every incentive to work around
constraints in the network layer - the more barriers an SP puts up, the
harder the application developer will work to punch through them. So the
question is, should you create those barriers when they're actively and
intentionally being overcome?


More information about the ipv6-ops mailing list