IPv6 prefix from T-Mobile USA used but not announced in BGP (2607:7700::/32)
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
On Wednesday, April 27, 2016, Baptiste Jonglez <baptiste@bitsofnetworks.org> wrote:
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
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
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.
2607:7700:0:25::4e00:605b
4e00:605b -> 78.0.96.91 -- Aaron
On Wednesday, April 27, 2016, Aaron Hopkins <lists@die.net> 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.
2607:7700:0:25::4e00:605b
4e00:605b -> 78.0.96.91
-- Aaron
Apple has also required the ability for ipv6-only operations https://developer.apple.com/news/?id=08282015a
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
On Wed, 27 Apr 2016, Baptiste Jonglez wrote:
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.
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
participants (3)
-
Aaron Hopkins -
Baptiste Jonglez -
Ca By