It would be helpful if you can quote exactly the part on which you are
requesting
my opinion.
This part:
It actually does qualify. I believe (though I could be wrong) state
information and communication buffers are the biggest memory spending for
network operations.
There _could_ be a trade-off between the transient NAT with its
processing power toll and the persistent /net-import with its memory
cost. However, systems like FreeBSD pre-allocate and always keep a number
of network buffers so the processing power toll for transience almost
vanishes if the kernel is fine-tuned for its load. By contrast, on a
large network /net-import strategy could make a "powerful" gateway
unavoidable because every machine on the network will need a session with
the gateway even if it only rarely communicates with the outside world,
unless you implement an uglier-than-NAT client-side dial-on-demand.
And this:
There is a huge difference. Almost as much difference there is between
NAT and RSVP.
Where importing /net is compared to RSVP because it uses a persistent
application layer overlay to do a job that is usually done with transient
connections. In case of RSVP there's a motive to do that, in case of NAT,
well, NAT solutions already exist and work pretty well--I've actually been
saying that /net-imported may be useful (!= usable) for some applications I
don't know about but very probably not for NAT.
What field?
Out of the field := clueless, a soccer player who follows the ball outside
the field
I am only familiar with Linux implementation.
Which is only a small subset of iptables, right?
Yes. And that's the NAT that *I* and a million Linux lemming out there
are familiar with.
Not right. As late as SuSE v9.0 people used the much lighter and less
sophisticated "masquerading" ipmasq which didn't involve iptables
(beginning with v10's iptables became the default). It was the Linux
equivalent of the sort of half-assed "NAT" that importing /net will give
you. Easy but incomplete.
In case of iptables as I pointed out before you have at your disposal a
very sophisticated tool--that you put the tool to uses it is too big for is
mostly your fault. There are many other Linux NAT solutions that do NAT
proper.
data structures to do its job. I'll leave it up to you to see how much
memory gets wasted on each connection.
Do you claim you have compared that to doing the same thing on Plan 9? If X
bytes of memory get used up for a task you don't call it a "waste of
memory" unless the task could be done with (X - x) bytes being used up.
I have no clue what netfilter does, thus I can't answer your question.
Netfilter (or NetFilter) is the larger framework iptables is part of. It
provides every conceivable capability at network layer--everything,
including NAT.
I thought the original discussion was dedicated to comparing an overhead
that the general purpose NAT box has with an overhead of a Plan9 box from
which /net was imported. Since I haven't seen specifics I gave the
example of a typical Linux NAT built using iptables. That's the area I'm
familiar with.
It's OK. But you haven't made any comparison of the overhead, yet.
Define port forwarding. And I really mean it: define. Then I can may be
offer a bit of functionality on Plan9 that would be capable of fitting
your definition.
The traditional definition of NAT is (of course) here:
<http://asg.andrew.cmu.edu/rfc/rfc1631.html>
Here's a definition of port forwarding:
<http://hasenstein.com/linux-ip-nat/diplom/node7.html#SECTION00071300000000000000>
However I give an operational definition which involves what is nowadays
_expected_ from any NAT solution:
A packet arrives at the gateway. Behind the gateway there is a machine
dedicated to serving FTP and another to HTTP, or two machines both
dedicated to serving HTTP that are meant to balance each other's loads. You
want the gateway to decide on how to rewrite the packet so that inbound
traffic to port 21 goes to the FTP machine and inbound traffic to port 80
goes to the HTTP machine, or the inbound traffic in one session goes to one
HTTP machine and the inbound traffic in another session goes to the other
HTTP machine. To add to the hassle you may also want--for security
reasons--to run your server software on other ports than 21 and 80, and the
gateway needs to rewrite the packet so that it reaches the right endpoint
(IP:port, in this case). The process shall be transparent to the internal
and external networks.
How should the two imported /net's on the two machines on the internal
network rewrite packets without becoming NAT re-invented?
--On Saturday, November 15, 2008 12:01 PM -0800 Roman Shaposhnik
<[EMAIL PROTECTED]> wrote:
On Nov 15, 2008, at 3:21 AM, Eris Discordia wrote:
Exactly! An idle TCP connection costs you nothing except the state
that
Would you mind reading my response, too, and then informing me of
your opinion?
It would be helpful if you can quote exactly the part on which you are
requesting
my opinion.
Not only that, but if you look at the amount of state something like
iptables on Linux needs to keep in order to provide NAT
capabilities it
becomes a complete toss.
You seem to be extremely out of the field
What field?
with respect to what iptables does and how normal NAT is implemented
on a *BSD system (which was my example).
I have no knowledge of how NAT is implemented on a *BSD system and thus
I can not comment. I am only familiar with Linux implementation. Thus if
that's
not what you're interested in discussing -- lets stop right now.
Iptables provides very sophisticated routing and filtering
capabilities. It's used as a back-end for stateful inspection,
packet rewriting, logging, routing, intrusion detection, and
firewalling applications. That's NAT... plus one million other
applications.
Yes. And that's the NAT that *I* and a million Linux lemming out there
are familiar with.
Arguing that your OS can do that in a simpler way is as useful as trying
to convince
Windows users to migrate to Linux 'en masse.
I'm unclear as to what "amount of state" iptables needs to keep
After you do something like:
# iptables -t nat -A POSTROUTING -p TCP -j MASQUERADE
the Linux kernel module called nf_conntrack starts allocating
data structures to do its job. I'll leave it up to you to see how much
memory gets wasted on each connection. Here's a hint,
though: /proc/net/nf_conntrack
that makes imported /net a "complete toss" assuming you can
magically make /net provide the same functionality netfilter does.
I have no clue what netfilter does, thus I can't answer your question.
I thought the original discussion was dedicated to comparing an overhead
that the general
purpose NAT box has with an overhead of a Plan9 box from which /net was
imported.
Since I haven't seen specifics I gave the example of a typical Linux NAT
built using
iptables. That's the area I'm familiar with. If you're interested in
something else -- there
are others on the list who might have an opinion.
Also, neither you nor anyone else have addressed the question of
port forwarding using an imported /net.
Define port forwarding. And I really mean it: define. Then I can may be
offer a bit of functionality
on Plan9 that would be capable of fitting your definition.
Thanks,
Roman.
