LiMe networks trick clients into thinking IPv6 is available

[nordurljosahvida]

Every since I started using LiMe, any client on the lan thinks the network is IPv6 enabled, even though the only gateway in the network is IPv4 only. This happens across every LiMe deployment I have.

root@ubuntu:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1350 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:0c:29:92:14:5a brd ff:ff:ff:ff:ff:ff
    inet 10.42.127.114/16 brd 10.42.255.255 scope global dynamic noprefixroute ens33
       valid_lft 2898sec preferred_lft 2898sec
    inet6 2a00:1508:a42:2400:65a1:d08b:f4f0:c0b0/64 scope global temporary dynamic 
       valid_lft 85694sec preferred_lft 85268sec
    inet6 2a00:1508:a42:2400:a74c:b3c1:31c7:10cd/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 85694sec preferred_lft 85694sec
    inet6 fe80::31f8:75e3:9044:a458/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

Therefore anytime a hostname has an IPv6 record associated in DNS, some clients, such as android devices, try using the IPv6 address, and of course connections fail.

I've noticed that an IPv6 range is generated in lime-defaults, why do those look like global addresses?

Thanks

[nicopace]

The relevant data would be `ip -6 r` Everyone gets an ipv6 address, but doesn't mean that you have a route assigned over it. Please let us know what is the output of that command. Thanks,

…

On 11/27/18 12:32 PM, Nicolas North wrote: Every since I started using LiMe, any client on the lan thinks the network is IPv6 enabled, even though the only gateway in the network is IPv4 only. This happens across every LiMe deployment I have. ***@***.***:~# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1350 qdisc fq_codel state UP group default qlen 1000 link/ether 00:0c:29:92:14:5a brd ff:ff:ff:ff:ff:ff inet 10.42.127.114/16 brd 10.42.255.255 scope global dynamic noprefixroute ens33 valid_lft 2898sec preferred_lft 2898sec inet6 2a00:1508:a42:2400:65a1:d08b:f4f0:c0b0/64 scope global temporary dynamic valid_lft 85694sec preferred_lft 85268sec inet6 2a00:1508:a42:2400:a74c:b3c1:31c7:10cd/64 scope global dynamic mngtmpaddr noprefixroute valid_lft 85694sec preferred_lft 85694sec inet6 fe80::31f8:75e3:9044:a458/64 scope link noprefixroute valid_lft forever preferred_lft forever | Therefore anytime an address is resolved in IPv6, some clients, such as android devices, try using the IPv6 address, and of course connections fail. I've noticed that an IPv6 range is generated in lime-defaults, why do those look like global addresses? Thanks — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#95>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABFX1dZcLIqQ6G5J7jrrKJIPN9aY6I7tks5uzYUjgaJpZM4Y2Fqj>.

[ilario]

It also happened to me, annoying, please check this: libremesh/lime-packages#236

[nordurljosahvida]

Thank you for the super fast reply.

Here it is:

root@ubuntu:~# ip -6 r
2a00:1508:a42:2400::/64 dev ens33 proto ra metric 100 pref medium
fe80::/64 dev ens33 proto kernel metric 100 pref medium
fe80::/64 dev ens33 proto kernel metric 256 pref medium
default via fe80::a8aa:aaff:fe42:24aa dev ens33 proto ra metric 100 pref medium

This is a VM running on my pc, but I'm using connection sharing rather than a bridge. However this issue happens on all devices I have, and on android devices especially, many apps do this. I think it also depends on how the ns resolution is performed. To give you a very specific example, the conversations XMPP client will try connecting to our server [ae.os.vu] and will always fail from any LiMe network. This is the result of a host query for this hostname:

root@ubuntu:~# host ae.os.vu
ae.os.vu has address 80.211.10.102
ae.os.vu has address 89.46.73.154
ae.os.vu has address 217.61.60.150
ae.os.vu has IPv6 address 2a00:6d40:72:7966::1
ae.os.vu has IPv6 address 2a00:6d41:10:109a::1

Thanks again

[nicopace]

Just helping to have as much information as possible for others to debug :) It looks like you have a default gateway... so if the DNS resolves to a AAAA record, it will try to use that. Perhaps the thread @ilario mentioned can help.

…

On 11/27/18 12:47 PM, Nicolas North wrote: Thank you for the super fast reply. Here it is: ***@***.***:~# ip -6 r 2a00:1508:a42:2400::/64 dev ens33 proto ra metric 100 pref medium fe80::/64 dev ens33 proto kernel metric 100 pref medium fe80::/64 dev ens33 proto kernel metric 256 pref medium default via fe80::a8aa:aaff:fe42:24aa dev ens33 proto ra metric 100 pref medium | This is a VM running on my pc, but I'm using connection sharing rather than a bridge. However this issue happens on all devices I have, and on android devices especially, many apps do this. I think it also depends on how the ns resolution is performed. To give you a very specific example, the conversations XMPP client will try connecting to our server [ae.os.vu] and will always fail from any LiMe network. This is the result of a host query for this hostname: ***@***.***:~# host ae.os.vu ae.os.vu has address 80.211.10.102 ae.os.vu has address 89.46.73.154 ae.os.vu has address 217.61.60.150 ae.os.vu has IPv6 address 2a00:6d40:72:7966::1 ae.os.vu has IPv6 address 2a00:6d41:10:109a::1 | Thanks again — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#95 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABFX1TJ3GstydOH3V31Yd_efx23UEiJKks5uzYjMgaJpZM4Y2Fqj>.

[nordurljosahvida]

Cool thanks. I hope we can figure this out. Let me know if any further data is needed.

[G10h4ck]

Nexthop should answer with an ICMP unreachable packet, if the client have no strange firewall rules it should be unnoticeable the delay caused by having the IPv6 default route