I won't react to anything that has been replied before me about the
utility of NAT in general. I obviously agree with those of you that
think it's worth a try !
On 15/07/11 01:15, Jan Engelhardt wrote:
As such, anything revolving around that topic is closely eyed and
dismantled. (The Linux camp generally being one that likes to DTRT and
cook their ideas through, at least more than some
purely-commercially-oriented huts.)
I don't like NAT either. But, by definition, RFC means Request for
Comments, and I don't know how to make any constructive comment without
trying to implement it, and see pros and cons...
As for the thesis paper:
- At times, the document reads like a speech, owing to certain
linguistic constructs such as enumerations, relatively short sentences
("election campaingn" style), and a somewhat abundant use of exclamation
marks.
I'm not seeing myself as an English-master, and this is the first real
big project I had in English, thus yes, I agree it can be difficult to
read. But I don't think we are on this list to criticize my level in
English.
This feature [NAT] is very common in IPv4 networks today - it made the
delay of the X-Day possible - and will surely have its applications in
IPv6 networks.
Possible yes, however, delaying of the x-day was surely not one of its
design goals. As such, the delay seems more like a side-effect at
first — and then when it became apparent that address space runs out
"soon", NAT became a constant abuse.
I don't see where I say "Its goal was" in this sentence. A constant
abuse, maybe, but an abuse that helped the most people to have an
Internet access at home. Some are conservative and will say it is not
such a good thing, but I'm not one of them. Some must have said the same
thing when the Television, next the phone have become so popular...
Let's not forget also that, the more people are using internet, the more
servers we need; and the more servers we need, the more IP addresses we
need; ...; quicker will be be the need of IPv6. And I think, as many
others, that it is time for IPv6 to come, not only for the number of
available addresses, but for many other reasons !
Side-effect is too soft. Calling NAT a security device comes like
premeditated deception of end-users.
I insisted enough on the fact that a NAT Device is NOT a security
device. And it IS a side-effect; too "soft" is somewhat psychologically
subjective.
But I didn't think either it was a primary and desired effect, until one
member of my jury, who is a recognized and well-known security expert,
told me that NAT has two primary interests in today's Internet :
Multi-Homing and... Security!
Having said that, I don't think "side-effect" is too soft!
There is a difference between needed address and available addresses. If
people did not need so many, they could fit all their hosts in the
available address space instead - and would not need NAT.
Yes. But these addresses were needed, thus they needed NAT. I don't
understand your point here.
In fact, each IPv6 hosts usually already has more than one address - and
one of them is the fe80::/ link-scope prefix. So they are generally
already multi-homed once one has added a unicast address to an
interface.
Yes, and these link-scope addresses are not routable, and if you add a
unicast address from the prefix of one ISP, another one will reject this
prefix. Therefore, the utility of NAT66!
Fast execution NAT in IPv4 is slowed because the NAT device has to
recompute the checksums every time a packet goes through; we want to
circumvent this limitation.
You need to recompute them anyway when doing L7 substitution.
Yes, that's something that remains to be done on the implementation I
provided. And my knowledge is that there is very more packets of L7
protocols that do not need a L7 substitution, than those that need!
Please, don't read : "there is few L7 protocols that need substitution"
; I'm talking about the volume of data transferred !
A 128-bit entity can very well be atomic if the programming language
implementation decides to make it so. Just because yours does not do it
currently does not mean it will never be.
Yes, but the title of my thesis say "in a Linux kernel", and I'm not
thinking that the kernel is compiled in a way that 128 bits are atomic !
But you're right on one point : I should have enlightened that by saying
"by the time of this writing, and in the Linux kernel".
This statement seems incorrect. One type's representation may be a trap
representation for another type. Again, just because that is not the
case in contemporary implementations does not mean it is not possible.
Same as before.
routers cannot fragment a packet on their own anymore, and cannot
reassemble fragments either.
While I can agree with this statement, be aware that "routers" running
nf_conntrack will undoubtedly reassemble in all cases, save perhaps for
packets delievered to raw sockets due to the order of raw-socket
delivery and nf_defrag.
My knowledge so far is that the reassembling routine in the conntrack
(in IPv6) is authorized only in the INPUT chain (Pierre Rondou, who is
from same University and has same jury of mine has been confronted to
this problem).
And if some modules in the kernel need to reassemble, I'm not, and I can
very well work with packet fragmented.
BTW, if you know a module/a way to reassemble a packet in transit in the
kernel, I'm curious to know it !
nf_conntrack (required by nf_nat) forces reassembly of
packets exactly because the L4 header is part of the tracking tuple.
In IPv6 also ?
int i; // A loop counter
“A loop counter!? Nobody would have expected _that_!”
What do you mean ?
If what makes you react is the comment, I will say "a comment not very
useful is more than nothing, which is approximately the level of comment
in the kernel, and that really is a pain in the ass when you're trying
to understand something ; and if I was the reader of this portion of
code, such a comment would surely not hinder me".
And if it's the fact that there is a loop counter that makes you react,
because it's a mistake, explain to me why this is a mistake would
certainly be useful !
This negotiation happens in a ASCII format data flow and not in a
binary format. Therefore, the change of the connection information in
the ASCII format may change the length of the packet after the NAT
manipulation.
Note however that binary encodings can also exist as variable-length. So
binary is not the magic scepter. Think of UTF-8.
What I meant here, is that the length of the IP address may change in
ASCII format (2001:db8:1::1 => 2001:db8:1:babe::1) has 5 more characters
in ASCII format. You can have a binary encoding which is
variable-length, you will never have the same number of bits in both cases.
--
Terry Moës (20061420)
Université de Liège - Faculté des Sciences Appliquées
2ème année Master Ingénieur Civil en Informatique - Délégué
Représentant Etudiant - Conseil de Faculté
FFSA Administrateur -http://www.ffsa.be
T.Moes@xxxxxxxxxxxxxxxxx
--
N-HiTec - Nova High Technology Engineering and Consulting
Responsable des Infrastructures - Vice-Président
Web :http://www.nhitec.com
Tél : 04/366.20.01
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
