IPv6 prefix from T-Mobile USA used but not announced in BGP (2607:7700::/32)

Mailman List Mirror (Read Only)
1

Hi,

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:

2607:7700:0:25::4e00:605b
2607:7700:0:25::4e25:8ce8
2607:7700:0:25::c808:db2c
2607:7700:0:4::3294:6683
2607:7700:0:4::4c09:4d39
2607:7700:0:4::5985:87d1
2607:7700:0:4::5d7d:3df8

All those IP are in 2607:7700::/32, allocated to T-Mobile USA but never
announced:

  https://stat.ripe.net/2607%3A7700%3A%3A%2F32#tabId=at-a-glance

What could explain their usage in an application? Some form of address
translation? Maybe these addresses have been used as source address in
outgoing packets, which would indicate IPv6 tests in T-Mobile? (but
obviously, nobody is able to answer such packets).

Baptiste

2

You see these addresses because your DHT is not supporting IP correctly.
Enable ipv6 and your flaw will be resolved and you will no longer see these
addresses.

CB

3

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.

2607:7700:0:25::4e00:605b

4e00:605b -> 78.0.96.91

                                     -- Aaron

4

Apple has also required the ability for ipv6-only operations

https://developer.apple.com/news/?id=08282015a

5

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

6

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

7

Based on http://dan.drown.org/android/clat/, it looks like it may be
possible for an IPv4-only application to connect to raw IPv4 addresses
through a IPv4-to-IPv6 NAT service on the Android device itself, which then
is transported over IPv6 to T-mobile's IPv6-to-IPv4 NAT device.

Skimming https://github.com/savoirfairelinux/opendht/blob/master/src/dht.cpp, my
guess is that new peers find your IPv4 address:port (on T-mobile's
IPv6-to-IPv4 NAT device) in the DHT and contact you, which somehow doesn't
get correctly translated back to IPv4 before it makes it to your
application, so you are seeing the untranslated IPv6 address. Replying to
the new peer on the T-mobile-internal IPv6 address should still work as long
as you stay on T-mobile's network but are of limited use otherwise.

                                     -- Aaron