Requirements for IPv6 Firewalls

William Herrin bill at
Thu Apr 17 18:05:39 UTC 2014

On Thu, Apr 17, 2014 at 12:15 PM, Fernando Gont <fernando at> wrote:
> Thanks so much for your feedback! One meta comment: this document is an
> Internet-Draft, not an RFC. It's just the second version (-01) we have
> published... so it's not meant to be there.

Hi Fernando,

I apologize; my tone was out of line.

> On 04/17/2014 12:51 PM, William Herrin wrote:
>> Also, I note your draft is entitled "Requirements for IPv6 Enterprise
>> Firewalls." Frankly, no "enterprise" firewall will be taken seriously
>> without address-overloaded NAT.
> Just double-checking: you're referring to NAT where the same address is
> mployed for multiple hosts in the local network, and where the
> transport-protocol port needs to be re-written by the NAT device?
> (i.e., a NAT-PT)

Correct. The "other" NAT, the one described in RFC 1631, is rather unloved.

>> I realize that's a controversial
>> statement in the IPv6 world but until you get past it you're basically
>> wasting your time on a document which won't be useful to industry.
> That's certainly controversial in the IPv6 world, but I have no problem
> with that. This sort of input (even much better if more people weigh) in
> is exactly what we're looking for. Such that when we apply the
> corresponding changes, and folks from other circles complain about them,
> I can point them to this sort of discussion.

Here's the drill: From an enterprise security perspective, deploying
IPv6 is high risk. I have to re-implement every rule I set on my IPv4
addresses all over again with my IPv6 addresses and hope I don't screw
it up in a way that lets an adversary wander right in. That risk is
compounded exponentially if the _initial_ deployment can't follow an
identical security posture to the IPv4 system. Without availability of
the kind of NAT present in the IPv4 deployment, I have a problem whose
solution is: sorry network team, return when the technology is mature.

There's a fair argument to be made which says that kind of NAT is
unhealthy. If its proponents are correct, they'll win that argument
later on with NAT-incompatible technology that enterprises want. After
all, enterprise security folk didn't want the Internet in the
corporate network at all, but having a web browser on every desk is
just too darn useful. Where they won't win that argument is in the
stretch of maximum risk for the enterprise security folk.

Bill Herrin

William D. Herrin ................ herrin at  bill at
3005 Crane Dr. ...................... Web: <>
Falls Church, VA 22042-3004

More information about the NANOG mailing list