From owner-freebsd-net@FreeBSD.ORG  Tue Dec 30 08:32:55 2003
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 89D4216A4CE
	for <net@FreeBSD.org>; Tue, 30 Dec 2003 08:32:55 -0800 (PST)
Received: from tenebras.com (laptop.tenebras.com [66.92.188.18])
	by mx1.FreeBSD.org (Postfix) with SMTP id 8492E43D31
	for <net@FreeBSD.org>; Tue, 30 Dec 2003 08:32:54 -0800 (PST)
	(envelope-from kudzu@tenebras.com)
Received: (qmail 20073 invoked from network); 30 Dec 2003 16:32:53 -0000
Received: from sapphire.tenebras.com (HELO tenebras.com) (192.168.188.241)
  by laptop.tenebras.com with SMTP; 30 Dec 2003 16:32:53 -0000
Message-ID: <3FF1A8B5.30807@tenebras.com>
Date: Tue, 30 Dec 2003 08:32:53 -0800
From: Michael Sierchio <kudzu@tenebras.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, zh-tw, zh-cn, fr, en, de-de
MIME-Version: 1.0
To: net@FreeBSD.org
References: <20031228221511.91095.qmail@web21509.mail.yahoo.com>
	<20031230081308.GA36953@FreeBSD.org.ua> <3FF151F3.A5D9EC19@freebsd.org>
In-Reply-To: <3FF151F3.A5D9EC19@freebsd.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Source Routing
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Dec 2003 16:32:55 -0000

Andre Oppermann wrote:

> Ruslan Ermilov wrote:

>>What is missing in ipfw(8) and its ``fwd'' option from being a
>>successful implementation of policy routing?
> 
> 
> In the technical sense it is.  For larger systems you want automatic
> configuration from a routing daemon.  ipfw also has its limits when
> it comes to a large number of prefixes which are changing all the
> time.

A policy or multi-protocol routing daemon can *effect* the desired
policy via ipfw.  My original notion was to do this via divert
sockets, but for appliance devices this requires horsepower which
is not available, and involves too much kernel-userland packet
copying.