Dynamic addressing based on IP address?

[reixd]

@TMRh20
What do you think. Could be useful to extract the IP address from the TUN/TAP device (last 16 bits) and use that as a dynamic addressing mechanism for the RF24Network?

[TMRh20]

Yeah, I think here definitely needs to be a defined or defineable relationship between the IP and the RF24Network addresses, but haven't thought too much yet about how it would work best given the differences and similarities between routing in IP vs RF24Network.

[TMRh20]

Come to think of it, the RF24Network addressing is directly relatable to IP addresses, and this could be an optional feature or even become the default for addressing, since more people probably understand IP routing compared to the octal system used.

RF24Network Address format	IP Address Format
40-bits (5-bytes)	32-bits (4-bytes)
byte 0: Pipe number	n/a
bytes1-4: Node address	bytes 0-3: Node Address

So, if we used a mask of 10.10.10.10 for example, the master node could be 10.10.10.10
n = 1-5
Direct children of master would be 10.10.10.n/24 using a gateway of 10.10.10.10
Children of those nodes would be 10.10.n.n/16 (Node 10.10.5.5 uses gateway 10.10.10.5)
Subsequent subnets/levels could use similar topology, and routing is all IP-based, regardless of whether you are addressing things from the RF24Network or RF24toTUN viewpoint.

I haven't thought it through all the way, but it seems to have potential. Thoughts?

[reixd]

I started a wiki page https://github.com/reixd/RF24toTUN/wiki/RF24Network:-Dynamic-Addressing to collect all the ideas and thoughts about dynamic addressing and routing.
I have other thoughts and ideas about this topic, I will update the wiki accordingly.

[reixd]

Your proposal could work :)
I think we could use this kind of addressing. It would be useful for applications which rely on IP networking capabilities and would work routing the frames across the network.

About dynamic addressing: what do you think about this.

• if the application using rf24lib gives an address as a parameter, then use the given address as a RF24Address
• else, collect 4 bytes of randomness (arduinos could use thermal noise in the GPIO pins) and "create" a RF24Address with these bytes and set the IP of the TUN/TAP device. Using random addresses the probability of address collision could be reduced.
• Another possibility would be using DHCP (https://www.ietf.org/rfc/rfc2131.txt) and RF24toTUN, but not really useful with arduinos
• I thought we could use some of the IPv6 ideas, like based on the MAC address build the IPv6 address. Therefore my idea of generating a random MAC and based on that automagically generate an IP address.
  • It would be also nice to use both v4 and v6 address, (we should think of the future). Luckily v6 could be build based on the v4 address. Should be no problem.
  • But there is a problem on using dynamic addressing: routing. We can not use static routing like your schema. Therefore my second proposal: using B.A.T.M.A.N as a routing protocol.
  • BATMAN (https://en.wikipedia.org/wiki/B.A.T.M.A.N., http://www.open-mesh.org/projects/open-mesh/wiki) is a sort of light OLSR protocol. We could either use it with the linux kernel and the routing daemon and RF24toTUN or implement a basic routing algorithm in the RF24Network lib.
  • BATMAN must only know if there are other nodes out there and which direct route should it take.
    • For this purpose "hello messages" with TTLs are broadcasted across the network
    • When A receives a "hello message" from C over B, A knows it can reach C over B and saves this info in the routing table. More information is not necessary.
  • I omitted a couple of extra procedures and steps, but the main idea is pretty simple and it works in a real live environment ;) The protocol is actively developed by the Freifunk people in cities like Berlin.
  • The arduinos do not need to save a big routing table. I think a realistic number of entries would be 30 to 50 routes. This could save some of the precious RAM...
  • If the beacons interval is not too high it should not affect the throughput much.

Together, with dynamic addressing and BATMAN routing across the network could be possible. An it would be robust if the layout changes often.

We could implement both routing schemes: static and BATMAN.

Any ideas? Thoughts?

I know, I know, ambitious plans ^^