Pierky's Blog

You know when in the morning you wake up and a thought flashes across your mind? One of these mornings I had this: how many RIPE Atlas probes are on a NAT64/DNS64 scenario? RFC7050 can help to answer this question.

A small digression on RFC7050…

Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis

RFC7050 describes a best-effort method to learn IPv6 prefixes used in NAT64 scenarios.

TL/DR: ipv4only.arpa is a well-known domain name with only two A records that always resolve two special purpose global IPv4 addresses: 192.0.0.170 and 192.0.0.171. If a node is in a DNS64/NAT64 scenario, when it tries to resolve the ipv4only.arpa domain name using a DNS64 box it receives back a response containing IPv6 addresses in the Pref64::192.0.0.[170|171] format, where Pref64 is the prefix used by the DNS64 resolver to synthesize the NAT64 destination (for example, the 64:ff9b::/96 RFC6052 prefix). So, response minus 192.0.0.[170|171] = Pref64.

What can it be used for?

Well, mostly to solve two problems that arise in a NAT64/DNS64 scenario when

1. applications are instructed to establish a connection using address literals or
2. a local DNSSEC validating stub resolver is used.

The first issue here described is due to the fact that applications don’t use DNS at all when they try to reach a destination by using its IPv4 literals, so the DNS64 box can’t do its magic of synthesizing an IPv6 address to use for NAT64. By implementing RFC7050 an application can recognize the NAT64 scenario and build the NAT64 destination address on its own.

The second issue is due to the fact that a local validating stub resolver must receive all the original records in order to perform its local validation, so the DNS64 can’t send back an adulterated response. Here, again, a validating stub resolver which implements RFC7050 can receive and validate the original data and finally it can use the Pref64 prefix to synthesize the NAT64 address and pass it to the requesting application.

RIPE Atlas probes behind DNS64

So, back to the original question: are there RIPE Atlas probes behind DNS64?

I used two RIPE Atlas tools to start and then analyze some measurements using probes that have IPv6 connectivity; these tools are Magellan (the official command-line client for RIPE Atlas) and RIPE Atlas Monitor.

The method I used can be found on this Gist. The final result is: among 1600 probes, 7 look like to be behind a DNS64 box, on 5 different Autonomous System.

Measurement ID 3606764:
 ipv4only.arpa.            AAAA   2a02:1388:2040:0:0:0:c000:aa
 ipv4only.arpa.            AAAA   2a02:1388:2040:0:0:0:c000:ab: 1 time (1 unique probe), probe ID 12946 (AS29247, GR)

Measurement ID 3606765:
 ipv4only.arpa.            AAAA   64:ff9b:0:0:0:0:c000:aa
 ipv4only.arpa.            AAAA   64:ff9b:0:0:0:0:c000:ab    : 4 times (2 unique probes), probe ID 16725 (AS5617, PL), probe ID 16736 (AS5617, PL)

 ipv4only.arpa.            AAAA   2a01:568:0:0:0:6464:c000:aa: 4 times (2 unique probes), probe ID 753 (AS43950, GB), probe ID 2589 (AS43950, GB)

Measurement ID 3606766:
 ipv4only.arpa.            AAAA   2a01:568:0:0:0:6464:c000:aa: 2 times (1 unique probe), probe ID 4481 (AS198864, GB)

Measurement ID 3606767:
 ipv4only.arpa.            AAAA   64:ff9b:0:0:0:0:c000:aa
 ipv4only.arpa.            AAAA   64:ff9b:0:0:0:0:c000:ab: 1 time (1 unique probe), probe ID 22638 (AS18200, NC)

The following two tabs change content below.

• Bio
• Latest Posts

Pier Carlo Chiodi

Italian, born in 1980, I started working in the IT/telecommunications industry in the late '90s; I'm now a system and network engineer with a deep knowledge of the global Internet and its core architectures, and a strong focus on network automation.

Latest posts by Pier Carlo Chiodi (see all)

• Good MANRS for IXPs route servers made easier - 11 December 2020
• Route server feature-rich and automatic configuration - 13 February 2017
• Large BGP Communities playground - 15 September 2016