IPv4-to-IPv6 connectivity
To topBackground information
SIIT (Stateless IP/ICMP Translation) and NAT64 are technologies meant to communicate networking nodes which only speak IPv4 with nodes that only speak IPv6.
On the one hand, SIIT, also called Stateless NAT64, mangles packets, simply replacing IPv4 headers and IPv6 headers as described in [RFC 7915]. This method uses 1:1 address mapping and defines a class of IPv6 addresses called IPv4-mapped addresses, which have the prefix ::ffff:0:0/96 and may be written as ::ffff:a.b.c.d, where the IPv4 formatted address a.b.c.d refers to an IPv4-only node. This algorithm can be used in a solution that allows IPv4-only hosts to talk to IPv6-only hosts and vice versa.
On the other hand, Stateful NAT64 masks several IPv6 nodes behind an IPv4 address and thus it uses N:1 address mapping. NAT64 handles an IPv4-embedded IPv6 address as described in [RFC 6052] in which 32 bits have an IPv4 address encoded in them. The prefix can be 64:ff9b::/96 (well-known prefix) or a network-specific one defined by the Administrator. This algorithm can be used when an IPv6-only host needs to communicate with an IPv4-only host. Furthermore, it also uses a special DNS variant, DNS64 [RFC 6147], as a companion protocol.
Stateless NAT64
KTBRN1 Thread Border Router supports Stateless NAT64. There is an option in the “Settings” page in KiBRA Web Administration Panel where the Administrator can enable or disable this feature.
KiBRA uses internally the IPv4 prefix 10.46.0.0/24 to perform the 1:1 address mapping within the Thread Network. Therefore, every IPv6 address assigned by DHCPv6 to any Thread device is mapped to an unique IPv4 address within that prefix. For instance, in this use case, the IPv4 addressing would be the following:
| Thread device | IPv6 address | IPv4 address |
| BR1 | fd00:7d03:7d03:7d03::a2e:79 | 10.46.0.121 |
| R1 | fd00:7d03:7d03:7d03::a2e:bf | 10.46.0.191 |
As can be seen, the address mapping is done converting the IPv4 dotted decimal address 10.46.0.121 into 0a2e:0079 hexadecimal [10 = 0a hex; 46 = 2e hex; 0 = 00 hex; 121 = 79 hex] and embedding it into its own IPv6 prefix, fd00:7d03:7d03:7d03::/96. The result is an IPv4-embedded IPv6 address fd00:7d03:7d03:7d03::a2e:79.
In the following picture, the IPv4 addressing for each of devices has been added to the network diagram.
It must be taken into account that the KTBRN1 device doesn’t advertise the IPv4 route 10.46.0.0/24 over the LAN, so the Hosts residing there don’t know how to reach out this IPv4 destination. Hence it is necessary to add a static route that indicates who is the gateway for the IPv4 prefix 10.46.0.0/24. From an elevated command prompt, type the following command in the PC:
C:\> route ADD 10.46.0.0 MASK 255.255.255.0 192.168.1.54
Validation
It is time to test whether there is IPv4-to-IPv6 bi-directional communication between Thread devices and the Host residing on the LAN. From the LAN side, Thread devices are directly reachable by their IPv4 addressing within IPv4 prefix 10.46.0.0/24, and from the Thread Network side, Host is reachable by its IPv4-mapped IPv6 address that is ::ffff:192.168.1.60.
The ping test results seen from PC side are the following:
The ping test results seen from R1 side are the following:
