Re: NAT66 : A first implementation

["Terry Moës" <T.Moes@student.ulg.ac.be>]

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@student.ulg.ac.be

-- 

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html