On Wed, Apr 27, 2016 at 02:38:41PM -0700, Ca By wrote:

What behavior do you expect when an ipv6only node connects to an ipv4only node , which is the tmobile case? How is that address of the address report?

As far as I know, IPv4-only DHT nodes do not directly communicate with IPv6-only DHT nodes, I don't see how this would be possible in general. The code of the DHT client is here: https://github.com/savoirfairelinux/opendht

On Wednesday, April 27, 2016, Baptiste Jonglez <baptiste@bitsofnetworks.org> wrote:

...

On Wed, Apr 27, 2016 at 01:16:28PM -0700, Aaron Hopkins wrote:

...

On Wed, 27 Apr 2016, Baptiste Jonglez wrote:

...

While doing statistics on the participants of a public DHT, I was surprised to see some IP addresses that are not present in the DFZ:

I believe those are used by T-mobile's 464XLAT (RFC 6877) implementation.

Recent Android on T-mobile is IPv6-only and has no ability to connect to raw IPv4 addresses. T-mobile's DNS servers are only asked by these devices to translate hostnames to IPv6 addresses. If they can't find an IPv6 address, they will look up the IPv4 address for a hostname, and pack it into the bottom 32 bits of an IPv6 address that routes to a IPv6-to-IPv4 NAT device.

Thanks, I had forgotten that DNS64 is possible without using the well-known prefix. The encoded IPv4 addresses seem to belong to other peers of the DHT.

So, if this is basically DNS64/NAT64, these IP addresses should not be seen as source or destination address outside of T-Mobile's network, and are not attached to the interface of any device.

I can see two possible explanations:

1/ packets with src or dest IP in 2607:7700::/32 somehow escaped T-Mobile's network, without being translated back to IPv4. They caused other DHT nodes to believe they have incoming peers in 2607:7700::/32.

2/ there is an interesting bug in the DHT software when run behind 464XLAT (btw, the DHT is dual-stack and supports IPv6 just fine)

I still wonder how this can happen, because the DHT does not use DNS at all...

Baptiste