Requirements for IPv6 Firewalls

Simon Perreault simon at per.reau.lt
Fri Apr 18 18:06:17 UTC 2014


Le 2014-04-18 14:00, William Herrin a écrit :
> On Fri, Apr 18, 2014 at 1:40 PM, Simon Perreault <simon at per.reau.lt> wrote:
>> Le 2014-04-18 13:35, William Herrin a écrit :
>>> Your document specifies "Enterprise" firewalls. Frankly I think that's
>>> wise. Consumer and enterprise users have very different needs and very
>>> different cost points.
>>
>> Over here we have no use for IPv6 NAT. We have our own PI space. I
>> suspect many other enterprises would be in a similar situation.
>>
>> I totally get your position, but I don't see how it can justify an
>> Internet-wide requirement.
> 
> As I understand your document, you're trying to scope a set of minimum
> required features for a firewall that will be able to describe itself
> as "RFC whatever compliant." The idea is for folks working for large
> enterprises to be able to use such a tag as a discriminator for
> potential purchases. Since a pretty humongous number of them are using
> NAT with IPv4 and are likely to want to do so with IPv6, leaving that
> out of the required feature list seems counter-productive to your goal
> of a document which has utility to them.
> 
> Besides, you have spam control and URL filtering in there. Do you
> seriously propose that spam control and URL filtering rank above NAT
> on the *firewall* requirements list?

Well, it's not *my* document, but I'm very interested in it.

IMHO it should not be a shopping list of features that people might
want. The goal should not be to be a base for RFPs.

IMHO, what the IETF can do is recommend a set of behavioural traits that
make IPv6 firewalls behave like good citizens in the Internet ecosystem.
Meaning that a firewall that obeys those requirements will not break the
Internet. For example, passing ICMPv6 Too Big messages is important to
not break the Internet.

I think we can get consensus on such requirements, and I think it would
fit the IETF's role. A feature shopping list, not so much.

Simon




More information about the NANOG mailing list