Nice and clear explanation certainly for newbie like me for IPv6. I ran the similar lab as for practise, and I ran into some troubles which want to check with you.
The IP: 192.168.12.3, is this the actual IPv4-only host IP, or this is an translation IP which you made for NAT64? in your diagram, if i have a IPv4 only PC behind R1, and IPv6 only PC behind R3. how would that translation is going to be looks like? I see you declear a stateful prefix in the configure, but also configure as static mapping, is this kind of stateless or?
for your R1, i have a PC behind a router, run IPv4 only. The PC IP: 192.168.0.100
interface GigabitEthernet0/0/0/1
description "IPv4 only host"
ipv4 address 192.168.0.1 255.255.255.0
for your R3, i have a PC behind a router, run IPv6 only, the PC IP: 2407:400:3:4::1
interface GigabitEthernet0/0/0/1
description "facing to ipv6 only host"
ipv6 address 2407:400:3:4::/64
so in this case, if I want to ping from IPv6 only host to IPv4, what would be the IP should i use, and from v4 to v6? I am bit confuse of that translation IP in the static mapping part.
The IPv4 address in this configuration is the translated IP address. In other words, from the point of view of R1 and all of the IPv4 world, the IP address 192.18.12.3 will be used to gain access to R3. This IP address exists only within R2, but from R1âs perspective, it is the IP address that corresponds to the intended destination host which is R3. R3 has no knowledge of this IPv4 address.
In your case, you are adding routing between the PC subnets on each router and the NATed subnets. Because of this, you will not be able to create a static mapping to correspond to a PC that exists in another subnet, and not in a directly connected subnet. As a result, wonât be able to successfully communicate between the PCs because the NAT64 operation must take place between two directly connected networks. If you want to reach the PC which, from the point of view of the other PC, is behind a NAT64 router and behind a second router as well, you will be required to perform regular NAT on R1 and R3 as well. This becomes more complex and would not generally be implemented.
Hi Rene,
Thanks for the write up. Can we use it for production network? If so how can we know the destination V6 ip of a service . Like here we put static entry for 192.168.23.3 to v6 ip.
You can indeed use this configuration for a production network. What actual IPv4 and IPv6 addresses you will use depend on the implementation. If the whole environment is within your own private network, and youâre not connecting to the Internet, then you can safely use any IPv4 or IPv6 addresses you like. If you connect to the Internet, then it depends on where the edge of your network is. If the R3 router is part of the ISP network, then the ISP will give you the IPv6 address range you can use.
Hi Laz,
Thanks for your reply . I thinks to make the NAT64 workable we need the static entry for everythingâs . Suppose we want to communicate with GOOGLE DNS .So need the below entry on NAT64 Router must .
nat64 v6v4 static 2001:4860:4860::8888 8.8.8.8
(When R1 hit to 8.8.8.8 it will translate to its V6 address)
nat64 v6v4 static 2001:4860:4860::8844 8.8.4.4
(When R1 hit to 8.8.4.4 it will translate to its V6 address)
So in production how I know the IPV6 ip against an ipv4 ip. I thinks it s not scalable .
If you wanted to allow the translation of Googleâs DNS server, then yes, this would be the way to do it. However, as you said it is not scalable. Remember that NAT64 was developed in order to allow an IPv4 and IPv6 network interact. NAT64 is not a solution to solve connectivity for all types of resources. Protocols such as SIP, SDP, FTP and some applications such as Skype may not function correctly.
However, NAT64 is designed to function along side DNS64 allows the use of DNS hostnames thus simplifying translation. You can find out more about NAT64 and DNS64 and some examples of implementation at the following Cisco documentation:
Hi Rene and staff,
IPv4-Embedded is either WKP (Well-Known Prefix) or NSP (Network-Specific Prefix) unique to the organization, following the format decsribed in RFC 6052
In the lesson, Rene chose NSP with the last pattern prefix::/96
So, this is IPv4-embedded IPv6 for NAT64
RFC 4291 defines also IPv4-mapped IPv6: ::ffff:0:0/96
I donât find what IPv4-mapped is used for (?): could you clarify ?
I have been reading about IPv6 for a while and never saw an example about utilization of ipv4-mapped (??)
Regards
RFC 4038 has a good explanation of the use of IPv4-mapped addresses. An excerpt from the RFC follows:
Most implementations of dual stack allow IPv6-only applications to
interoperate with both IPv4 and IPv6 nodes. IPv4 packets going to
IPv6 applications on a dual-stack node reach their destination
because their addresses are mapped by using IPv4-mapped IPv6
addresses: the IPv6 address ::FFFF:x.y.z.w represents the IPv4
address x.y.z.w.
The RFC continues in detail explaining how this feature is used.
Hi Laz,
thanks for your answer: i missed RFC 4038, and this is a very good source to understand, and i found also very interesting the link you gave above to cisco white paper about âEnterprise IPv6 solutionâ (but it will take a little time to read it from beginning to end)
To clarify i will say there are two types of translation
when the host (client or server) is doing the translation. That is with dual-stack (on the client or on the server): in this case ipv4-mapped ipv6 are used
when the router is doing the translation (obviously in this case the hosts are not dual-stack): IPv4-embedded ipv6 address are used with Network Specific Prefix (NSP) or Well-Known Prefix (WKP)
Is it right ?
So, this will lead me to ask 2 questions:
in the 2 cases above, does the translation is the same ? that is using the same algorithm (IP/ICMP algorithm) to do the translation; that is, could we say that the translation in dual-stack is also NAT64 ? with 2 types: statefull and stateless ? [ 3 questions in one ]
reading RFC 4038 page 9, case IPV6-only server, i donât understand what is the wildcard address used by IPv4 client application (i know what wilcard mask is in ACL). IPv4 client app should send data using the IPv4 destination address of the dual-stack node ? what is wildcard address and its role in this case ?
Regards
It looks like the algorithms are the same. The only thing that changes is the prefix from 0:0:0:0:0:0::/96 to 0:0:0:0:0:FFFF::/96. This seems to be the same as what is going on for NAT64. There really is no algorithm involved beyond simply saying that the last 32 bits will be interpreted as an IPv4 address. Itâs just a matter of the involved devices understanding under what conditions this is to take place.
Just a note, that the documentation involved uses so many different terms such as IPv4 mapped, IPv4 Compatible, IPv4 Embedded, IPv4-Converted, and IPv4-Translatable just to name a few, that itâs not always clear which are standardized and which are just part of regular conversation. I think however that you have worked out the meaningsâŚ
The use of the term wildcard address is indeed unexpected. However, my understanding is that this is another term for the mechanism of extracting an IPv4 address from the IPv6 address. The wildcard address is the 96 zeros followed by 32 ones in binary or 0::1111:1111, which simply tells the device which part (the last 32 bits) is the IPv4 address.
thanks Laz, helpful,
and i found a link that, in a very short way, makes me better understand SIIT versus NAT64
I enjoy to share it https://www.jool.mx/en/intro-xlat.html
Regards
Dear, I carried out this laboratory keeping the R2 with the 1905 Router and replacing the R1 and R3 with notebooks. I can ping from 192.168.12.1 to 192.168.12.3. However I am not successful in dripping from 2001: DB8: 2323: 2323 :: 2 to 3001 :: C0A8: C01. The output of the show nat64 translations command follows:
NAT64#show nat64 translations
Proto Original IPv4 Translated IPv4
Translated IPv6 Original IPv6
--------------------------------------------------------
icmp 192.168.12.1:1 [3001::C0A8:C01]:1
192.168.12.3:1 [2001:DB8:2323:2323::3]:1
--- --- ---
192.168.12.3 2001:DB8:2323:2323::3
Total number of translations: 2
Looking at the output and the description you have shared, I donât immediately see anything that may cause this problem. Since you are able to ping in one direction, the translation is actually taking place successfully. This means that the translation in the other direction should work too.
However, I suggest you run a debug similar to that in the lesson, to see where the pings fail. You may want to enable icmp debug on R2 as well. Once you do that, and you determine where they are failing, you may also want to debug nat64 on R2 using the debugs described in this Cisco documentation:
Let us know of your troubleshooting progress, to see if we can be of further help.
For this particular lab, you can use any of the most common emulators available including VIRL, GNS3, and EVE-NG to name a few. Ideally, if you have real equipment, it would be beneficial to use that, however the emulators are more than enough for most of the labs required for Cisco certifications.
For more info about emulators, take a look at this lesson, which is relevant for any level Cisco certification:
Firepower does support NAT64, but the configuration may differ somewhat. Typically, using Firepower, you would set this up using the GUI provided. More information about NAT64 and similar technologies for Firewpower can be found here:
If you have any further more specific questions, please let us know!!
]