NAT principles of IPv6 and MAP66

NAT principles of IPv6 and MAP66 1. Why is NAT not recommended in IPv6 standards? This is a problem. As I explained earlier, IPv4 NAT breaks the Internet's "interconnection" feature, making some IP addresses no longer accessible in two directions, NAT adds a direction to the IP protocol without direction, especially the stateful NAT type. However, IPv4 NAT is designed to save IP addresses, rather than adding the direction of IP addresses and hiding private IP addresses. These are just some side effects that cannot be avoided. The IPv6 era has arrived. As long as it is not extended to outer space, all the ants on the earth can use IP devices. Some IPv4 repair methods will no longer be needed. To maintain the purity of the Protocol itself and related standards, IPv6 will hardly mention NAT. Although I will not mention it again, it does not mean that "You are not you". It is still possible to implement IPv6 NAT, and it is necessary in some cases.
2. the title of RFCRFC6296 is IPv6-to-IPv6 Network Prefix Translation, which describes the key points of NAT implementation in IPv6, and gives a reasonable suggestion, which not only keeps the IP direction, NAT stateless can satisfy the meaning of NAT, which is the reason for NAT stateless in IPv6. You can no longer expect to configure a rule as in IPv4 NAT, and then generate a rule in the opposite direction dynamically, in the case of IPv6, You need to manually configure the rule in both directions. 3. The IP addresses of the IPv6 subnet and NAT can be divided into several segments, including the network prefix, subnet ID, and host ID, which are no different in IPv4 and IPv6. In order to save IP addresses, NAT of IPv4 addresses, that is, the addresses in the IP address pool that can be mapped are smaller than or far smaller than the number of internal hosts, therefore, it is very likely that multiple internal hosts are mapped to the same external IP address. How can we distinguish them? Therefore, we have to introduce information such as the layer-4 protocol and port, that is, we are familiar with quintuple information. Therefore, most IPv4 NAT implementations are based on quintuple streams, which ensures the uniqueness of NAT information items maintained by the kernel, at the same time, many side effects are introduced. Www.2cto.com
IPv6 addresses hold nearly 128 locations that can be allocated at will. Due to the large address space, the general unit is allocated to a network segment with a large number of addresses, this CIDR block has enough addresses to map to the Intranet host. That is to say, the pool capacity of IP addresses that can be mapped is enormous. The key is how to maintain one-to-one ing, since you do not want to use non-IP layer information to maintain information, you need to use the information of the pure IP layer, which minimizes the impact on the upper layer. For IPv4, classic NAT uses a quintuple to retain the stream ID information. For IPv6, it is even better. Instead of using the checksum algorithm, no matter who the checksum is, because it does not change the packet checksum... 4. the relationship IP address between IPv6 and link layer identifies a host, while the MAC identifies a network interface, which is actually a one-to-many relationship. However, in reality, an IP address is often associated with a network card, one reason is that the link layer routing information can be automatically generated. This is very convenient. However, for IPv4 addresses, they are configured by themselves or allocated through DHCP. The management process is very complicated and address conflicts may occur accidentally, we have to rely on ARP broadcast, RARP, and other technologies to detect this situation. The reason for this is that the layered concept is too conventional. Who said IP and link layers cannot be associated, who said that the IP indicates that the host cannot be associated with the NIC; second, because the IPv4 address space is too small, and the MAC address length generally exceeds the IP address, although the one-to-many relationship meets the RFC standard, but it is inconvenient to use. IPv6 solves this problem, which slows down the address conflict and almost disappears. We know that the MAC address is a physical device that can be seen and touched. Sometimes, you may encounter static electricity. The MAC address is the same as your ID card number, ing MAC addresses to IPv6 addresses solves the major problem of IP address conflicts, which is also beneficial to NAT, which affects automatic address translation, each internal address that does not repeat is converted to an external address that does not repeat. All of this is due to the huge address space of IPv6 and can be used by other users.
5. It is a good explanation for the independence of checksum and automatic conversion. It should be understandable after graduation. Consider a + B + c + d = X www.2cto.com where X is checksum. We regard a and B as the two parts of the source IP address, and c and d as the two parts of the destination IP address, we convert the source address and change both a and B. For example, if a is changed to A, we can change B to a number to keep the checksum value X unchanged. This is actually very simple, it is a simple one-dimensional equation. We recommend that you implement NAT in IPv6 based on this principle, except that the one-dimensional equation above is a real number field, which is a Boolean number field in the computer. Since the checksum value of the layer-4 can be avoided, the impact of NAT on the layer-4 protocol will be reduced, although it still cannot solve the problem of cross-NAT, such as ESP/AH. Based on the above algorithm, when performing NAT, IPv6 can automatically generate a new IP address for ing within the specified subnet CIDR block. From the perspective of the algorithm itself, the possibility of conflict is very small to 0. The above practice is almost impossible for IPv4, because the IPv4 address space is too small, and the address pool capacity of each unit is limited, you cannot expect an algorithm to generate an IP address for you, because the generated IP address does not belong to you at all. The IP address conflict, or duplicate, conflicts with other mappings.
Since the IPv6 NAT mechanism "automatically" selects an IP address for a connection, how can we convert the returned packet back to the original one? We know that IPv6 NAT no longer uses quintuple to maintain NAT ing information, nor does it maintain such information in the kernel. Therefore, the "switch back" issue depends entirely on the algorithm itself, it is precisely because the algorithm itself can convert the converted address back to the original one. It is based on the uniqueness of the solution of the one-dimensional equation given at the beginning of this section. In the NAT Implementation of IPv6, the algorithm automatically generates 16-bit IP address information only, while other IP addresses need to be manually configured explicitly. Because Intranet IPv6 addresses can be mapped to unique IP addresses using MAC addresses, because of the uniqueness of the solution of the one-dimensional equation, the converted address is also unique. In turn, it can be mapped back to the original IP address. If we leave address translation alone and only consider the algorithm itself, we can still provide a code that can actually run. The Code uses the algorithm for calculating checksum: [plain] # include <stdio. h> # include <stdlib. h> # include <string. h> // The following two functions calculate the Verification Code. For detailed principles, see RFC1071/RFC1624/RFC1141 static inline u_int16_t add16 (u_int16_t a, u_int16_t B) {a + = B; return a + (a <B);} static inline u_int16_t csum16 (const u_int16_t * buf, int len) {www.2cto.com u_int16_t csum = 0; while (len --) csum = add16 (csum, * buf ++ ); Return csum;} int main (int argc, char ** argv) {u_int16_t buf [18] = {0}; int I = 0; memcpy (buf, "efghhijk", 8); memcpy (buf + 4, "12345678", 8); memcpy (buf + 8, "xxyywert", 8); memcpy (buf + 12, "zxcvkljh", 8); // the correct method is to print hexadecimal data. For simplicity, printf ("original data: % s length: % d \ n ", (char *) buf, strlen (char *) buf); printf (" original data verification code: % X \ n ", csum16 (buf, 16); u_int16_t tip [3] = {0}; memcpy (tip, "# $! % ", 4); u_int16_t tip_sum = csum16 (tip, 2); printf (" \ nNAT rule: efghhijk1234/12-> efghhijk # $! %/12 \ n "); printf (" fixed from the first byte to the fourth byte: % s. The verification code is % X \ n ", (char *) tip, tip_sum); www.2cto.com // locate the Fixed Initial address after dynamic modification. Note that, we only modify the 16-bit information u_int16_t * pcsum = buf + 4 + 2; // calculate the dynamically modified value * pcsum = ~ Add16 (add16 (~ (* Pcsum ),~ Csum16 (buf + 4, 2), tip_sum); printf ("dynamically modified value: % X \ n", * pcsum); memcpy (buf + 4, tip, 4); // complete printf modification ("current data: % s length: % d \ n", buf, strlen (char *) buf )); printf ("current verification code: % X \ n", csum16 (buf, 16); printf ("------------- The following is the restore operation ------------- \ n "); printf ("\ n reverse NAT rule: efghhijk # $! %/12-> efghhijk1234/12 \ n "); u_int16_t tip2 [3] = {0}; memcpy (tip2," 1234 ", 4 ); printf ("we only need to remember the original data before fixed modification: % s \ n", tip2); u_int16_t tip_sum2 = csum16 (tip2, 2 ); u_int16_t * pcsum2 = buf + 6; www.2cto.com * pcsum2 = ~ Add16 (add16 (~ (* Pcsum2 ),~ Csum16 (buf + 4, 2), tip_sum2); // restore memcpy (buf + 4, tip2, 4); printf ("Raw data: % s \ n ", (char *) buf); printf ("original verification code: % X \ n", csum16 (buf, 16);} the running result is as follows:

The results are remarkable. Applying the above principles to IPv6 NAT is an implementation. 6. If MAP66 www.2cto.com on Linux has an idea, someone will always implement it. Besides, if it is not just an idea but a standard, it is even more reasonable to implement it. Linux is a melting pot and an experimental field. The latest developments in some drafts always reflect Linux, and IPv6 NAT is no exception. MAP66 is a Linux implementation that basically follows the RFC6296 recommendation. It is easy to compile and install. For details, see its README. Would you like to give it a try? It is very simple, just like iptables of IPv4:
1. configure a forward conversion rule to convert the source address fdca: ffee: babe:/64 CIDR block to 2008: db8: 1 :: /IP address of the 64-bit network segment ip6tables-t mangle-a postrouting-s fdca: ffee: babe:/64-o eth2-j MAP66 -- src-to 2008: db8: 1 :: /64, we can see that no specific address is explicitly specified, similar to the IPv4 MASQUERADE and IPv4 IP Pool. For details, see section 5th. 2. configure the conversion rules of the reverse packet, and convert the address converted from the forward packet back to ip6tables-t mangle-a prerouting-d 2008: db8: 1 :: /64-I eth2-j MAP66 -- dst-to fdca: ffee: babe:/64, you can see that no specific address is explicitly specified, it is worth mentioning that the kernel does not maintain any information about NAT ing, so MAP66 no longer depends on ip (6) _ conntrack. If the above two rules can be enabled, ping the peer address. The result of tcpdump packet capture is as follows:

Author dog250