Make Meshenger working through routed networks

[bodems]

This is not an issue, but some ideas I have to make Meshenger working through routed networks. The problem: layer 2 networks don't scale. Many Freifunk communities already split up their networks in different layer 3 domains to reduce overhead and to improve performance. Different devices in different domains still can talk to each other, but they have different network prefixes and you can't use the link local address anymore. Also you don't know in what domain your peer device is, and so you don't know the IP. Maybe you can guess the prefix, but if we assume a /64 for each domain and a /48 for the whole network, you have 65536 possibilities. Of course you can enter all known used prefixes in your app (they are not much), but that's not really user friendly. So there is a need for a "signaling system", which should, of course, not be a centralized service. This can be done by a small daemon on the layer 3 routers, which connect the different domains. Meshenger already knows the IP of the router, because the device has an IPv6 default route received via router advertisements from the router. If Meshenger can't find the peer locally, it could ask the router if it knows a (routable) IPv6 address for the MAC of the peer. The router then looks up its neighborhood tables from other domains and returns the global routable IPv6 address of the peer. If the router doesn't find an address for the searched MAC, it even could ask other routers! Of course, this method is not perfect and has some problems:

Problems:

• Privacy hell: If you know a MAC, you can track its position (or at least in which domain it is). But if you know all used prefixes, you also can ping it.
• You can also collect a lot of meta data on the routers (who has contacted who at what time?). Wouldn't be possible (or at least not so easy) without such a signaling system.
• You need daemons on every router between the peers
• So this method doesn't work, when you are not in such a network (e.g. if you want to contact someone who is behind a private DSL line)
• There is definetly something I'm missing

Maybe there is a better solution at all?

[mwarning]

A slightly different idea that that would work without the necessity to modify the mesh node firmware.

• when a contact is shared, also transmit a list of possible signaling servers that can be asked (that is how webrtc works on the Internet)
• apart from a typical signaling server address/domain, transmit the last address part instead (e.g. ::3242) and attach that to the network prefix. If the the local IPv6 prefix is fdef::/0 => fdef::3242 is the signaling server.

[thereyougo]

Maybe adapt the torrent DHT model?

Otherwise as mentioned in other similar projects: UUCP

[mwarning]

A DHT keeps the wifi chip busy and as a result drains the battery. That is why it is not successfully used on phones.

[T-X]

Throwing in another idea:

• Similar to IPv6 Neighbor Discovery "Solicited-Node Multicast Addresses" (see RFC4861 and RFC4291) generate a "Meshenger Peer Discovery" Multicast Address.

Example:

• Take the /64 interface identifier of the link-local IPv6 unicast address
• Attach a multicast prefix with a scope greater than link-local (for instance ff15:... for site-local or even ff1e:... for global)
• (Maybe shorten/map the interface identifier if the multicast prefix is > /64, which depends what method is used for the multicast prefix generation, see RFC3306 or RFC3956 for instance)

On the gateway routers use https://github.com/troglobit/pim6sd to interconnect the various domains for IPv6 multicast. We are currently in the process of resurrecting this dusty layer 3, IPv6, PIM routing daemon. Also checkout https://md.darmstadt.ccc.de/dn42-multicast (this will move to the dn42 wiki eventually).

On the batman-adv and Gluon side routable IPv6 multicast support will hopefully land soon. Patches are available, reviewing and adjustments are in progress (batman-adv, Gluon).

Advantages:

• No need to implement a client<->server model, a more decentral approach
• MLD + PIM will take care of the whole announcement and announcement-routing process
• On the client side you'd only need to:
  • Implement a multicast listener to receive discovery requests
  • Implement a multicast sender to transmit discovery messages
  • Implement a response via unicast which contains a list of routable unicast addresses to use for meshenger for further communication
• "Scalable multicast" by using identifier->multicast-address mapping instead of bothering the whole mesh with one multicast address used by all devices (which for instance Bittorrent BEP-14 does, which is "not so scalable", and would result in battery issues even worse as with a DHT)
• Meshenger would then be a great "test application" and use-case for routed multicast :-). And could serve as a blueprint and example for other, decentral applications wanting to use the multicast infrastructure below.

[mwarning]

Thank you for the idea! It would be great to make the app working in other community networks as well.

So that I understand this correctly:

• this would enable enable direct calls in layer 3 networks with the help of multicast groups and pim6sd.
• for gluon/batman-adv meshes the current approach using IPv6 link local works already, but the multicast approach you propose would also work in the future.

To implement your proposal, the contact database would need to be store support multiple ways to communicate. And the in the settings those things need to be configured in the settings. An the of course the network code would need to be added. While this is not a topic for the GSoC, any pull request to add this feature would have my support.

Btw., Meshenger so far only supports this way to reach other contacts:

• eui64 link local ipv6 (fe80::ff:fe:)
• contact via IPv4/IPv6 address (also submitted via QR-code) - but this approach is not really promising These are also examples for possible contact methods:
• via hostname/DNS that would return a reachable address
• use local IPv6 /64 prefix and attach target eui-64 suffix (if such sort of address exists for the own device)

[T-X]

So that I understand this correctly:

• this would enable enable direct calls in layer 3 networks with the help of multicast groups and pim6sd.

• for gluon/batman-adv meshes the current approach using IPv6 link local works already, but the multicast approach you propose would also work in the future.

Basically yes. The thing is, currently we have several communities which have split their batman-adv networks into multiple domains with their own subnet each. So in those communities you would either be unable to use the Meshenger between those domains. Or you would need some manual work to feed and update things like your DNS support.

A multicast based discovery protocol similar to the one used by IPv6 NDP would provide an automised way to find a routable unicast address for a given identifier (MAC address, eui-64 suffix, public key, ...). So very similar to a DHT, but only bothering your target and multicast routers in between.

And this would not only allow such discovery between the domains of a city, but for instance could also enable address discovery and communication between communities, for instance over BGP/dn42/Intercity-VPN. Without any manual work by the user, without central servers.

(so it's not so much a proposal "to work in the future", but to extend the range of the Meshenger, without sacrificing any of the benefits of the current link-local-address-QR-code approach)

[mwarning]

The simple description of this feature by T-X would be: A chat based on multicast groups to exchange each others IP address. :-)

[ToEatFreshBabies]

Why not ZeroTier?

https://github.com/zerotier

You need daemons on every router between the peers

BGP?

[mwarning]

@ToEatFreshBabies ZerotTier does not work properly on OpenWrt with "typical" hardware resources (4mb flash or 64mb RAM or low power CPUs).