[188968] in North American Network Operators' Group
Re: IPv6 prefix from T-Mobile USA used but not announced in BGP
daemon@ATHENA.MIT.EDU (Baptiste Jonglez)
Wed Apr 27 17:09:25 2016
X-Original-To: nanog@nanog.org
Date: Wed, 27 Apr 2016 23:09:15 +0200
From: Baptiste Jonglez <baptiste@bitsofnetworks.org>
To: Aaron Hopkins <lists@die.net>
In-Reply-To: <alpine.LRH.2.02.1604271306100.5863@namshub.die.net>
Cc: nanog@nanog.org
Errors-To: nanog-bounces@nanog.org
--jq0ap7NbKX2Kqbes
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Wed, Apr 27, 2016 at 01:16:28PM -0700, Aaron Hopkins wrote:
> On Wed, 27 Apr 2016, Baptiste Jonglez wrote:
>=20
> >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:
>=20
> I believe those are used by T-mobile's 464XLAT (RFC 6877) implementation.
>=20
> 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 devic=
es
> 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 i=
nto
> 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=
=2E..
Baptiste
--jq0ap7NbKX2Kqbes
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJXISp3AAoJEL4B7CKgTi5GwG8P/1oonmRBkSPhj8PpaJkEGrR1
tR7SaftQfN98bUF62ET9iaz16cKFxxwiediK2foESHiMQIG7wJ6ArEIiPRxQpXWD
0AZAhbt3Y12zX0W/J6BVK8TaU6zVLhaD22sNKlVl9QWkMPHseELSXNV6bxytS7FL
V7C0V/lna9Wkrv+6nrJvAwV+bA7yiBvfS9ctbvEvFy7rBmBdH25y/YBaFz5t5gNX
A1Hi9bBTGbvw1yzD88R3QZSZqkfBRK2esnNGNGeng4Fj0zqUXumAqXYG+P9N7nHt
b7bSYYu6jgeOg95LU2nQizUK1wOB0f1hJ28KrAoBMSsO58jbkhT37WSd5eKi4lw9
BtuiyDGjQIXWTn4gf8sO1u2+MhqZrzR7U9F/f49uxL9CvMgKKoJR6tcA8BKMj3Xi
rSQxPnNuE5umACU56Une/jSN0bwSyc9DhxY+MvG3/7btl8W4zZJEPiUHIG+6IOkZ
B64Wpz3LBb3kJt5YUden4udBj62SBp/vpYCnHGEXHPjuZ+teG1StMF9CXfErrzm6
KEaKodYQzj3y/OFHU0eUOwemgR9JsZnpeAMWHn6U8+SpqxQ5IdzUyBrESwh9TlcA
HbeCwxSB8nWh0tVPBgGcLoaedCvaX7DfhiihvURUKk+RUb+K3wKHgK+DwuQfxxSi
zJmdJHD1RLC76OQmvB4W
=I0sQ
-----END PGP SIGNATURE-----
--jq0ap7NbKX2Kqbes--
