Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC

Owen DeLong <> Mon, 12 August 2013 17:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A3BEC21F9BCA for <>; Mon, 12 Aug 2013 10:25:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.525
X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ekk+bl22AKyr for <>; Mon, 12 Aug 2013 10:25:49 -0700 (PDT)
Received: from ( [IPv6:2620:0:930::200:2]) by (Postfix) with ESMTP id 1D5E121F8616 for <>; Mon, 12 Aug 2013 10:22:15 -0700 (PDT)
Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by (8.14.2/8.14.1) with ESMTP id r7CHGfmN012709 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 12 Aug 2013 10:16:41 -0700
X-DKIM: Sendmail DKIM Filter v2.8.3 r7CHGfmN012709
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple;; s=mail; t=1376327801; bh=f+KT3F2yil1wT7j3EH+MSk9cQYw=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=Vlb5/JBCyF9c1OfEOw4+0uGg++IJJ5Cpq9W+eyokL+ceFuhMBVsVNvO7y+fFWkFYx p7mQo2iTYh/e2xmvVIrmktAsBWxxl8Tf3in8mE2o/qujUKn/xvDI3Vnxhz1nAjTVBS 8s21LyV/+RRj1GYhG/xxnm8wrKe7B5FcXQP5xinc=
Content-Type: multipart/alternative; boundary="Apple-Mail=_B2122261-0D1B-4650-A7C8-5B87F2BAB021"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Owen DeLong <>
In-Reply-To: <>
Date: Mon, 12 Aug 2013 10:16:43 -0700
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <>
To: "Arie Vayner (avayner)" <>
X-Mailer: Apple Mail (2.1508)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 ( [IPv6:2620:0:930::200:2]); Mon, 12 Aug 2013 10:16:41 -0700 (PDT)
Cc: "" <>
Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 12 Aug 2013 17:25:51 -0000

Not necessarily. You are thinking of moving them physically closer. I'm suggesting moving them topologically closer.

Imagine that the WN links are not private, but instead are public. Each site doesn't necessarily have a firewall, but it does need a VPN device (good practice anyway, since you can't trust your WAN links to be truly private[1]). These VPN gateways would have some level of mesh (ideally matching the phsyical topology relatively closely) to link the internal networks at all the sites over the WAN links. At that point, the firewalls may be physically at any or all of the internet gateway locations, but may serve different subsets of users or may be partitioned into virtual firewalls that are connected to different subsets of the internal network that travel through different VPNs, etc.

There are many ways to virtualize and abstract topology in order to enable this without necessarily increasing or moving physical hardware.


On Aug 11, 2013, at 22:27 , "Arie Vayner (avayner)" <> wrote:

> Owen,
> While the arguments about moving the firewalls closer to the users are valid they are often are not practical (or at least the customers I worked with would not implement this option).
> Imagine an enterprise network with 300 spoke sites, but only 2 or 3 Internet gateway locations (with some private WAN in between).
> Moving the firewalls to the spoke sites would increase the number of firewalls from ~3 to ~300 (I am ignoring redundancy and scale for a second)… This is a major CAPEX and OPEX impact…
> Arie
> From: Owen DeLong [] 
> Sent: Friday, August 9, 2013 12:17 PM
> To: Arie Vayner (avayner)
> Cc: Eric Vyncke (evyncke); Lorenzo Colitti; Fred Baker (fred);
> Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC
> On Aug 8, 2013, at 22:21 , Arie Vayner (avayner) <> wrote:
> Another loosely related point that I think could make sense in such a document would be the ways to accomplish multi-homing and how it is different than today’s IPv4 implementations.
> Many enterprises rely on NAT on the Internet edge as their multi-homing/traffic engineering mechanism with IPv4.
> If we recommend against ULA+NPTv6 (or just NPTv6 for traffic engineering), then we need to highlight the symmetry requirement due to stateful security layers.
> Traffic leaving from an Internet gateway site to the Internet has to come back through the same site, or the stateful firewalls would break the flow (well, has to hit the same stateful security layer)
> Or stateful firewalls have to get better about sharing state. There are two things that can help with this...
> 1.         Put your firewalls as close to the end systems they protect as possible. Make your security zones relatively small and place the firewalls closer together at those narrower borders.
>             This will often require more firewall units, but it helps in a number of ways:
>             A.        Firewall policy tends to be much simpler (and as a result less error prone and more reliable)
>             B.        The hardware demands on the firewall tend to be lower so you can buy cheaper units.
>             C.        The simpler rulesets can be more easily tailored to meet business requirements as they evolve.
> 2.         Improve firewalls. Give the firewalls that all protect the same boundary a way to mesh-peer with each other and exchange information about the state tables such that triangle routing is no longer problematic.
> Syncing upstream and downstream routing policies is not always an easy task (but could be relevant in some cases).
> Linking the Internet gateway layer across sites (before hitting the stateful security layer) could be another solution.
> If we make the changes above to the firewalls, this could be  a lot less relevant in most cases.
> Do you think a short discussion to raise awareness for this potential issue could be relevant in such a document?
> It's certainly worth documenting. I'm not sure whether it belongs in this document or not.
> Owen