Hi, Continuing in English for the mailing list, Indeed, we can't do much about NAT addresses and we already have the same issue for IPV4-only NATed addresses. Those addresses fill the routing tables with unreachable nodes, but the DHT is supposed to handle that by ignoring them after trying to reach them.
We could at least handle the case of addresses with the known prefix, keeping them as-is in the IPv4 table instead of IPv6, and translating them to the corresponding IPv4 for transmission to other peers. Adrien From: "Baptiste Jonglez" <bapti...@bitsofnetworks.org> To: "Adrien Béraud" <adrien.ber...@savoirfairelinux.com> Cc: "ring-dev" <ring-...@lists.savoirfairelinux.net> Sent: Friday, April 29, 2016 1:24:50 PM Subject: Re: Strange IPv6 behaviour with opendht Salut, On Fri, Apr 29, 2016 at 01:03:14PM -0400, Adrien Béraud wrote: > Salut Baptiste, > Merci pour ton mail et ton analyse, ces information nous sont précieuses. > Comme tu le mentionnes, ce comportement est probablement causé par un NAT64 > lors de l'utilisation de Ring Android sur un réseau GSM. > Ce pourrait être lié à la technologie de traduction d’adresses de T-Mobile > USA https://tools.ietf.org/html/rfc6877 > > Dans ce cas OpenDHT devrait détecter ces adresses, les insérer telles quelles > dans la table IPv4 (au lieu d'IPv6), > et les traduire en "vraies" IPv4 pour la transmission aux autres peers. > Ce comportement te semblerait-il correct ? Ça me paraît difficile : c'est facile de repérer le « well-known prefix » 64:ff9b::/32, en revanche ce n'est pas simple de détecter qu'une adresse comme 2607:7700:0:a::5a4c:f258 est utilisée pour encoder une IPv4. En fait, le problème est plus général et concerne toutes les adresses qui ne sont pas globalement visibles. Par exemple, si un pair A connaît un pair B via une adresse RFC1918, il va l'annoncer au reste de la DHT, mais aucun autre pair ne pourra contacter B. En soit, ça ne semble pas si gênant, ça consomme juste des ressources inutilement (certains pairs de la DHT vont essayer de contacter les adresses non-globales, sans succès). Ce qui serait intéressant, c'est de comprendre d'où viennent ces adresses. Si la traduction IPv4 - IPv6 était faite correctement, l'application (ici, Ring/opendht) ne devrait même pas se rendre compte qu'il y a eu une traduction. Merci de ta réponse, Baptiste > From: "Baptiste Jonglez" <bapti...@bitsofnetworks.org> > To: "Adrien Béraud" <adrien.ber...@savoirfairelinux.com> > Sent: Friday, April 29, 2016 3:37:41 AM > Subject: Re: Strange IPv6 behaviour with opendht > > Btw, I've attached the script I used to parse opendht messages (it's > completely ad-hoc and probably miss a lot of corner cases, but it works). > Do a packet capture on UDP and pass it to the script: > > tcpdump -w opendht.pcap -i eth0 udp > python pcap_opendht.py opendht.pcap > > Baptiste > > On Fri, Apr 29, 2016 at 09:33:16AM +0200, Baptiste Jonglez wrote: > > Hi Adrien, > > > > While looking at Ring's DHT for the usage report I sent yesterday, I > > noticed something strange with IPv6. I have no idea whether it's a bug > > (and if so, where), which is why I want to discuss it with you first. > > > > Basically, I see a lot of "incorrect" IPv6 peers in the DHT, for instance: > > > > 64:ff9b::60f8:7c61 > > 2607:7700:0:a::5a4c:f258 > > > > The full list is in attachment to this mail. > > > > The first one is in a special prefix, reserved for IPv4-to-IPv6 > > translation (see https://tools.ietf.org/html/rfc6052#section-2.1). > > 2607:7700::/32 is actually reserved for the same usage: it is allocated to > > T-Mobile USA, but not announced in the global BGP routing table. See the > > discussion here: > > > > http://mailman.nanog.org/pipermail/nanog/2016-April/085465.html > > > > You can decode the embedded IPv4 with this quick & dirty python3 script: > > > > import ipaddress > > def conv(x): > > a = ipaddress.ip_address(x) > > i = int(a) > > print("{}.{}.{}.{}".format((i & 0xff000000) >> 24, (i & 0x00ff0000) >> 16, > > (i & 0x0000ff00) >> 8, i & 0x000000ff)) > > > > >>> conv("64:ff9b::60f8:7c61") > > 96.248.124.97 > > >>> conv("2607:7700:0:a::5a4c:f258") > > 90.76.242.88 > > > > The encoded IPv4 addresses belong to (seemingly random) other peers of the > > DHT. > > > > As far as I know, it's a form of NAT64, i.e. encaspulating an IPv4 address > > in an IPv6 address, to allow end-devices to think that everybody talks > > IPv6. Usually, the mapping is done through DNS64, but I don't think this > > is the case here, because opendht doesn't use DNS. From the nanog > > discussion, it would seem that recent IPv6-only Android can themselves > > translate raw IPv4 communication (which opendht uses) into IPv6. > > > > I'm still not sure how those buggy peers appear in the first place, some > > DHT nodes must think they are valid peers. > > > > I have started to look at packet captures to decode the opendht messages, > > and I saw things like this: > > > > 1461864056.728726 2607:fb90:812b:3231:7f8e:5199:d105:6219:6142 → > > 2a00:5881:4008::42:8352 > > {'t': (b'fn', 29024), 'y': b'r', 'r': {'id': > > 'b579a84041e3231256e5800a5a1f429bff9197a8', 'token': > > '304907d124cc6d344df23da5f99c6c48538b930f1e5879ba9b85ddfeb714a1f927ae15a06fe89dd867e8419476648b7d7812b8a6c5877f8fd82eff9852be9b39', > > 'n6': [('b6bcd39cbae3d2ec7c06717b5d1efc469e2e0e20', > > IPv6Address('2607:7700:0:12::c05f:93f'), 4246), > > ('b542a7e42251acff95c449beb96c07eb834fda70', > > IPv6Address('2607:7700:0:12::c05f:93f'), 4231), > > ('b55626b80a7f09026ddc977505aff1a693089790', > > IPv6Address('2607:7700:0:12::1872:6344'), 52832), > > ('b3f22bd706eacf581c6f9bbc27d22958fedfcb59', > > IPv6Address('2001:41d0:a:1e4e::1'), 4377), > > ('b0e8b0ff673a968d19afdf3cd28b22e5ab333e2e', > > IPv6Address('2607:7700:0:12::c05f:93f'), 4294), > > ('b00ce4ddc79555df8cc38bfcefef2e5b827235aa', > > IPv6Address('2001:41d0:a:1e4e::1'), 4371), > > ('b011e522cd69765839bc0e3fff7be40b452daa28', > > IPv6Address('2607:7700:0:12::411d:aa29'), 6362), > > ('be4dc2b3b7fba34f28259897d5f81e9cffa66768', > > IPv6Address('2607:7700:0:12::c05f:93f'), 4292)], 'sa': > > IPv6Address('2a00:5881:4008::42')}, 'v': b'RNG1'} > > > > So, basically, 2607:fb90:812b:3231:7f8e:5199:d105:6219 (an IPv6 device in > > T-Mobile's network) is telling me about some buggy peers, for instance > > 2607:7700:0:12::c05f:93f and 2607:7700:0:12::1872:6344. In this case, the > > embedded IPv4 are 192.95.9.63, which seems to be your bootstrap server, > > and 24.114.99.68, in Rogers in Canada. > > > > If you want to discuss this further, I am available on Jabber: > > zo...@jeproteste.info (or through Ring, obviously, but not 24/24: > > ring:d2beebe96a69b21791e98ea640fce3ad764aa709). I'm in UTC+1, btw. > > > > Sorry for the long email :) > > Baptiste > > > 2607:7700:0:11::1872:2a0e > > 2607:7700:0:11::25c9:a922 > > 2607:7700:0:11::3e18:5b55 > > 2607:7700:0:11::4020:4b49 > > 2607:7700:0:11::40e4:1341 > > 2607:7700:0:11::506b:aaa3 > > 2607:7700:0:11::5279:aea5 > > 2607:7700:0:11::57b1:459a > > 2607:7700:0:11::59de:a48e > > 2607:7700:0:11::9a7e:6834 > > 2607:7700:0:11::b92c:97a4 > > 2607:7700:0:11::bc1d:a49e > > 2607:7700:0:11::d557:e03d > > 2607:7700:0:13::446f:487d > > 2607:7700:0:13::532:6e53 > > 2607:7700:0:13::53db:8752 > > 2607:7700:0:13::58ab:e0 > > 2607:7700:0:19::411d:aa29 > > 2607:7700:0:19::c0ab:202c > > 2607:7700:0:1c::446f:487d > > 2607:7700:0:1c::4ac5:43d2 > > 2607:7700:0:1c::532:6e53 > > 2607:7700:0:1c::5433:7e49 > > 2607:7700:0:1c::547d:2847 > > 2607:7700:0:1c::6c1b:e475 > > 2607:7700:0:1c::9185:bbc3 > > 2607:7700:0:1e::1888:7cc > > 2607:7700:0:1e::25bb:1e4e > > 2607:7700:0:1e::49fc:e57d > > 2607:7700:0:1e::4dfe:45ee > > 2607:7700:0:1e::53db:8752 > > 2607:7700:0:1e::53ec:9bf6 > > 2607:7700:0:1e::5899:680 > > 2607:7700:0:1e::6d6e:2831 > > 2607:7700:0:1e::804e:6946 > > 2607:7700:0:1e::c05f:93f > > 2607:7700:0:1e::c387:e813 > > 2607:7700:0:1e::c630:d5a9 > > 2607:7700:0:1e::c9f6:214 > > 2607:7700:0:1e::d4e7:2c66 > > 2607:7700:0:1e::d598:a24f > > 2607:7700:0:2::17e9:2213 > > 2607:7700:0:2::25bb:1e4e > > 2607:7700:0:2::29fb:d91f > > 2607:7700:0:2::4ac5:43d2 > > 2607:7700:0:2::4db6:b27f > > 2607:7700:0:25::17e9:2213 > > 2607:7700:0:2::5239:89e6 > > 2607:7700:0:25::29fb:d91f > > 2607:7700:0:25::326b:6f2c > > 2607:7700:0:25::4812:ae67 > > 2607:7700:0:25::4a6a:c92c > > 2607:7700:0:25::4e00:605b > > 2607:7700:0:25::4e25:8ce8 > > 2607:7700:0:25::5138:20cb > > 2607:7700:0:25::5239:89e6 > > 2607:7700:0:25::532:6e53 > > 2607:7700:0:25::5638:6493 > > 2607:7700:0:25::59f2:dbe2 > > 2607:7700:0:25::5a4b:89da > > 2607:7700:0:25::5f5b:e12e > > 2607:7700:0:2::5638:6493 > > 2607:7700:0:25::774c:36a3 > > 2607:7700:0:25::b39f:b62 > > 2607:7700:0:25::c0ab:202c > > 2607:7700:0:25::c808:db2c > > 2607:7700:0:2::5f5b:e12e > > 2607:7700:0:2::6c1f:be67 > > 2607:7700:0:2::6dbe:e40c > > 2607:7700:0:2::bb4b:f532 > > 2607:7700:0:2::bf27:40f1 > > 2607:7700:0:2::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 > > 2607:7700:0:a::411d:aa29 > > 2607:7700:0:a::532:6e53 > > 2607:7700:0:a::59d3:7989 > > 2607:7700:0:a::5a4c:f258 > > 2607:7700:0:a::c0ab:202c > > 2607:7700:0:e::17e9:2213 > > 2607:7700:0:e::29fb:d88e > > 2607:7700:0:e::3e91:cb31 > > 2607:7700:0:e::4a6a:c92c > > 2607:7700:0:e::4fb0:7c8a > > 2607:7700:0:e::532:6e53 > > 2607:7700:0:e::5f5b:e12e > > 2607:7700:0:e::b39f:b62 > > 64:ff9b::25bb:1e4e > > 64:ff9b::3e91:cb31 > > 64:ff9b::411d:aa29 > > 64:ff9b::414e:38fa > > 64:ff9b::4ac5:43d2 > > 64:ff9b::4d98:260c > > 64:ff9b::4e97:c266 > > 64:ff9b::501e:d9b3 > > 64:ff9b::532:6e53 > > 64:ff9b::53db:8752 > > 64:ff9b::581a:c388 > > 64:ff9b::59d3:7989 > > 64:ff9b::5f5b:e12e > > 64:ff9b::5f9a:5492 > > 64:ff9b::60f8:7c61 > > 64:ff9b::6c1b:e475 > > 64:ff9b::6c1f:be67 > > 64:ff9b::6cb5:c2e1 > > 64:ff9b::6dbe:e40c > > 64:ff9b::6dd9:74 > > 64:ff9b::774c:36a3 > > 64:ff9b::9234:6621 > > 64:ff9b::ac3a:2950 > > 64:ff9b::adf6:18d6 > > 64:ff9b::b90a:fc80 > > 64:ff9b::c05f:93f > > 64:ff9b::c0ab:202c > > 64:ff9b::d4e7:2c66
_______________________________________________ Ring mailing list Ring@lists.savoirfairelinux.net https://lists.savoirfairelinux.net/mailman/listinfo/ring
