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

Wed Apr 27 21:09:15 UTC 2016

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20160427/3708c075/attachment.sig>