On Thursday 2011-07-14 18:27, Terry Moës wrote: >>>Hi all ! >>> >>>Since the Draft of NPT66 (Stateless Mapping) has gone RFC >>>(http://tools.ietf.org/html/rfc6296), it's the good time for me to >>>publish my master thesis : an implementation, for Netfilter, of NAT >>>in IPv6, with both Stateless and Stateful approaches. >>> >>>It's published on Sourceforge : >>>https://sourceforge.net/projects/nfnat66/ >> >>Hm, how often has this been (re)implemented now... the last one was >>sf.net/projects/map66 > >If you are willing to compare this implementation, which just add two >targets to Xtables, with mine, which involves the Connection Tracking, >and is able to deal with icmp error messages, AND implements stateful, >n:1 mapping Of course yours is feature-richer. But the topic of IPv6 NAT has had come up a number of unrecollectable times, and the response has been the same everytime - NAT is still an ugly undesired hack whose recurrence wants to be avoided. 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.) 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. >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. >The NAT general principle is the modification of the addresses >information of IP packets in order to isolate all the network [...] >Security. The NAT Device often blocks packets unassociated to any >existing flow [...] this “application” is more a side-effect NAT is not a security device, even if a particular implementation with a particular configuration _may_ drop packets. A different implementation may even allow them by default — think certain router models with clearly labeled "DMZ" ports, and a user plugging stuff in without thinking. Side-effect is too soft. Calling NAT a security device comes like premeditated deception of end-users. >Multi-Homing. One network can be a client of several ISPs in order to >ensure redundancy or in order to reduce costs. These different ISPs >will assign the client different prefixes. However, it can be desired >that the client does not have to modify the topology of his subnet each >time he switches from one ISP to another. When switching the provider, consider: - If ISP2 blocks packets with source address SRC1, you are busted. NAT won't fix your problem: - reason 1: NAT is applied per CT and does not automatically change while a CT exists. - reason 2: Even if it did, packets of your connection would suddenly have SRC2, and the remote side would reject it with TCP RST, because it only knows a connection with SRC1. - If ISP2 does accept packets from SRC1 (last time I checked, HE.net and SIXXS.net did that), you don't need NAT either. These issues are known today already because they also apply to v4-NAT. The more so because in the providers' little IPv4 space, in practice ISPn almost always block sources claiming not to come from ISP2's space. >the main reason for using NAT in IPv4 was the ability to connect >several hosts of an internal network to an external network, using less >public IP Addresses than needed 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. >But, if there were only routing tables, there would be a problem with >prefixes: both ISPs would impose their prefixes, and the network inside >the company cannot have several prefixes. There is no reason that hosts inside a network are limited to a single address. There: ip addr add 2001:db8:1::1/64 dev dummy0 ip addr add 2001:db8:2::1/64 dev dummy0 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. >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. >An entity that is 128 bits long is never atomic 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. >And whatever is the type of the variable defined, the representation in >memory will remain the same. 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. >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. Subsequently, >We will thus have to be aware that some packets arriving have NO Layer >4 information while NAT is still working. is not satisfied. nf_conntrack (required by nf_nat) forces reassembly of packets exactly because the L4 header is part of the tracking tuple. >int i; // A loop counter “A loop counter!? Nobody would have expected _that_!” >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. So far my active readthrough.. -- 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
