On Friday 2011-07-15 11:16, Terry Moës wrote:
>>- 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.
Well, it is independent of English - the same atmosphere one can
construct with many indoeuropean languages. (“IPv6 n'est pas un
illusion, [n'est pas] un rêve, [n'est pas] une chimère, [n'est pas] un
concept obscur. C'est ici!” “IPv6 är inte en illusion, [inte] en dröm,
[inte] en chimär, [inte] en mörk koncept. Det är här!”)
If you have a French copy of the work, I am happy to read it.
>>>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.
You don't explicitly, but the subconscious sound is there. (Reads: "NAT
made the delay possible".)
>maybe, but an abuse that helped the most people to have an Internet
>access at home.
NAT is not a prerequisite to Internetworking.
>>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,
Routable or not, your host is essentially multi-homed already for a
particular group of hosts.
>and if you add a unicast address from the prefix of one ISP, another
>one will reject this prefix.
As I reported, this is not the case. At first I too thought this was a
bug that one ISP allows packets from another one's address space, but it
also seemed like a deliberate goal of IPv6.
>>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".
I meant the programming language implementation (e.g. compiler with a
hardware that offers a 128-bit atomic type), not adding atomic barriers
like spinlocks around IPv6 manipulations in the source code.
Maybe Dave knows whether "long double", which occupies 128 bits on
x86_64, is an example of an already-existing atomic type.
(And then there is __m128 too.)
>>>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).
>>nf_conntrack (required by nf_nat) forces reassembly of packets exactly
>>because the L4 header is part of the tracking tuple.
>
>In IPv6 also ? And if some modules in the kernel need to reassemble,
>I'm not, and I can very well work with packet fragmented.
Look at NF_IP{,6}_PRI_CONNTRACK_DEFRAG. It runs even before raw,
otherwise one could not reliably select packets to be -j CT
--notrack'ed. Cf.
http://www.spinics.net/lists/netfilter-devel/msg11656.html
>>> 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".
What code does, one can read from the source. Summaries are ok, like the
ones inside xt_find_target. Comments should more often explain why they
do something - and I agree there is a shortage of those in networking.
But // A loop counter would just be noise that does not add
documentation value. ("i" is concise, short, and if it were not used for
a loop, temporary or immediately obvious construct, you have a naming
issue according to LKCS chapter 4.)
--
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
