DragonFly BSD
DragonFly kernel List (threaded) for 2011-01
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

[no subject]


Date:

y=ZG@mail.gmail.com>
From: Francois Tigeot <ftigeot@wolfpond.org>
Subject: Re: Time to let go of ipfilter
Date: Sat, 22 Jan 2011 13:40:21 +0100
BestServHost: crater.dragonflybsd.org
List-Post: <mailto:kernel@crater.dragonflybsd.org>
List-Subscribe: <mailto:kernel-request@crater.dragonflybsd.org?body=subscribe>
List-Unsubscribe: <mailto:kernel-request@crater.dragonflybsd.org?body=unsubscribe>
List-Help: <mailto:kernel-request@crater.dragonflybsd.org?body=help>
List-Owner: <mailto:owner-kernel@crater.dragonflybsd.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
References: <AANLkTimjM2J4nQ9-Nuv3Z88pEdsbp8jYkKcUht=FwEuY@mail.gmail.com> <AANLkTind5QG_bZA+uhrT5BQqYmyNLsjq6YrzVWXLVWOm@mail.gmail.com> <201101211602.p0LG2mRv009793@apollo.backplane.com> <20110121193033.1B25919D496@mail.netbsd.org> <201101212217.p0LMH0P7017513@apollo.backplane.com> <72c983e5e708847d211383d03dbff6a0.squirrel@webmail.exetel.com.au> <AANLkTiku-VxZQzRDo1Bd5M-bpYgHKWkrKiKkeVa3Nube@mail.gmail.com> <20110122082312.GA990@sekishi.zefyris.com> <AANLkTik=S5O1DA78ObwEJ-paiUTdV5vEUM7LOym1
y=ZG@mail.gmail.com>
In-Reply-To: <AANLkTik=S5O1DA78ObwEJ-paiUTdV5vEUM7LOym1y=ZG@mail.gmail.com>
Sender: kernel-errors@crater.dragonflybsd.org
Errors-To: kernel-errors@crater.dragonflybsd.org
Lines: 38
NNTP-Posting-Host: 216.240.41.25
X-Trace: 1295700310 crater_reader.dragonflybsd.org 888 216.240.41.25
Xref: crater_reader.dragonflybsd.org dragonfly.kernel:14844

On Sat, Jan 22, 2011 at 08:04:17PM +1100, Edward O'Callaghan wrote:
> more my point, +1
> to EOL'ing older solutions that are no longer maintained or scalable.
> One of the things that I myself consider a 'feature' of Dragonfly is
> less old junk running in kernel space (both important on a security
> and stability stand point) and a less bulky userland.

Can't agree more.

Speaking of future packet filtering improvements, we also need NAT64
support.

Traditional NAT maps IP adresses between two IPv4 spaces; we may call
it NAT44 (IPv4 to IPv4).
NAT64 maps IPv4 addresses to an IPv6 space. It allows you to run an
IPv6 only network and still have access to legacy IPv4 resources.

It works in combination with a special DNS64 resolver which translates
A records to AAAA. AFAIK, DNS64 support is implemented in new versions
of most of the leading DNS daemons (Bind, Unbound, etc...).

DNS64/NAT64 is already used by some ISPs. I tested Andrews & Arnold's
gateway for a brief time; it worked flawlessly:

http://aaisp.net.uk/kb-broadband-ipv6-nat64.html

This technology allows you to shut down IPv4 on your network today and
still be operational.
There are patches for OpenBSD 4.6 pf here:

  http://ecdysis.viagenie.ca/index.html

Some links on this subject:
http://www.networkworld.com/community/blog/testing-nat64-and-dns64
http://www.viagenie.ca/publications/2009-11-06-3gpp-ietf-ipv6-shanghai-nat64.pdf

-- 
Francois Tigeot



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]