From owner-freebsd-net@FreeBSD.ORG  Mon Feb  7 13:03:05 2005
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 CDB2C16A4CE; Mon,  7 Feb 2005 13:03:05 +0000 (GMT)
Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su
	[213.184.65.80])	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 0C66043D60; Mon,  7 Feb 2005 13:03:02 +0000 (GMT)
	(envelope-from eugen@kuzbass.ru)
Received: from kuzbass.ru (kost [213.184.65.82])j17D2vAo064760;
	Mon, 7 Feb 2005 20:02:57 +0700 (KRAT)
	(envelope-from eugen@kuzbass.ru)
Message-ID: <420766FF.714B372D@kuzbass.ru>
Date: Mon, 07 Feb 2005 20:02:55 +0700
From: Eugene Grosbein <eugen@kuzbass.ru>
Organization: SVZServ
X-Mailer: Mozilla 4.8 [en] (Win98; U)
X-Accept-Language: ru,en
MIME-Version: 1.0
To: Gleb Smirnoff <glebius@freebsd.org>
References: <200501250834.11393.darcy@wavefire.com>
	<20050207124637.GE91619@cell.sick.ru>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
cc: freebsd-net@freebsd.org
cc: Darcy Buskermolen <darcy@wavefire.com>
Subject: Re: ng_nat revisited
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: Mon, 07 Feb 2005 13:03:05 -0000

> D> It's been a while since the subject of ng_nat appeared on-list, I'm wondering
> D> if there has been anymore work done on this?
> 
> Now I'm trying to work on this. I don't guarantee any success in recent future.
> 
> The first step is porting libalias to be a kernel module. I have already
> patches to make it compilable as kernel module, however with some features
> disabled - alias monitoring, sockets, and ipfw punching. The first two can
> be abandoned, but ipfw punching needs to be reimplemented in kernel.

Why do you think alias monitoring may be abadoned?

Eugene Grosbein