diff --git a/assets/u/image/k8s-v6-v4-dns.png b/assets/u/image/k8s-v6-v4-dns.png
new file mode 100644
index 0000000..eab1caf
Binary files /dev/null and b/assets/u/image/k8s-v6-v4-dns.png differ
diff --git a/content/u/blog/kubernetes-making-dns-publicly-reachable/contents.lr b/content/u/blog/kubernetes-making-dns-publicly-reachable/contents.lr
index ce32c8c..0970ed0 100644
--- a/content/u/blog/kubernetes-making-dns-publicly-reachable/contents.lr
+++ b/content/u/blog/kubernetes-making-dns-publicly-reachable/contents.lr
@@ -151,6 +151,33 @@ Keep-Alive: timeout=5
 (attention, this is a test service and might not be running when you
 read this article at a later time)
 
+## IPv6 vs. IPv4
+
+Could we have achived the same with IPv4? The answere here is "maybe":
+If the kubernetes service is reachable from globally reachable
+nameservers via IPv4, then the answer is yes. This could be done via
+public IPv4 addresses in the kubernetes cluster, via tunnels, VPNs,
+etc.
+
+However, generally speaking, the DNS service of a
+kubernetes cluster running on RFC1918 IP addresses, is probably not
+reachable from globally reachable DNS servers by default.
+
+For IPv6 the case is a bit different: we are using globally reachable
+IPv6 addresses in our k8s clusters, so they can potentially be
+reachable without the need of any tunnel or whatsoever. Firewalling
+and network policies can obviously prevent access, but if the IP
+addresses are properly routed, they will be accessible from the public
+Internet.
+
+And this makes things much easier for DNS servers, which are also
+having IPv6 connectivity.
+
+The following pictures shows the practical difference between the two
+approaches:
+
+![](/u/image/k8s-v6-v4-dns.png)
+
 ## More of this
 
 We are discussing