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#SECTION00071300000
000000000>
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.
