So, I had a crazy idea the other day:
Normally, when I talk to people about mesh networks, they assume that there is some central authority assigning IP addresses to nodes intelligently.
I was thinking, though, that I'd rather have it so that every node could have the same firmware, and you'd just throw the node up and it'd negotiate everything for itself, including its IP address.
So I was thinking: What if each node in the network was using batman-adv, and ran a DHCP client and a DHCP server? It'd try to get an address thru DHCP. If it failed, it'd choose an address at random from the network range. Then, any time someone threw up a new node in range, the new node would try to get an address, and it would succeed in getting an address from the first node.
Multiple DHCP servers can serve the same, overlapping IP ranges. However, this depends on the DHCPOFFER and DHCPREQUEST being broadcast to the network. This is how we avoid having the same IP address assigned to multiple nodes -- DHCP servers overhear what was assigned to whom by other DHCP servers, and make a note to themselves not to assign that address themselves.
So it seems that a "distributed" DHCP system could work.
The problem is, doesn't Batman-adv munge the DHCP that flows though it, for its gateway logic? So that the DHCPREQUESTs are unicast? That's great for gateway logic. But I also want nodes to have IP addresses for internal communication.
I was thinking of running it like this: Each node has two virtual interfaces - the mesh interface, running in adhoc mode. Routers use this interface, and this is where the distributed DHCP runs.
Another wifi interface runs in host mode. This is what laptops and so forth will connect to.
Once a router gets an ip address from this distributed DHCP nonsense, then it determines a longer network prefix for its clients on the host-mode interface. It sets up its HNAs and starts serving DHCP with this longer prefix to its clients. The machines on the inside run webservers and so forth that should be available to the inside of the mesh.
Now, what if the network is fractured and the same IP address gets assigned to a router (and thus is used as a prefix for that router's clients) on each side of the split? When the segments join up, we'll have multiple nodes with the same IP address and this will cause problems.
Yes. The lease times will be very short, so this type of problem should resolve itself quickly.
But, what do I do about how the gateway business interferes with DHCP? Could I somehow have two DHCP servers serving the same interface? One that serves out IP addresses and one that deals only with gateways?
Is this idea just too crazy? Why?
--Ryan
Spam detection software, running on the system "dedicated37.virtbiz.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details.
Content preview: So, I had a crazy idea the other day: Normally, when I talk to people about mesh networks, they assume that there is some central authority assigning IP addresses to nodes intelligently. I was thinking, though, that I'd rather have it so that every node could have the same firmware, and you'd just throw the node up and it'd negotiate everything for itself, including its IP address. [...]
Content analysis details: (10.3 points, 5.0 required)
pts rule name description ---- ---------------------- -------------------------------------------------- 0.5 HELO_LH_HOME HELO_LH_HOME 3.1 AXB_HELO_HOME_UN HELO from home - untrusted -1.5 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 1.2 RDNS_NONE Delivered to internal network by a host with no rDNS 4.3 TO_NO_BRKTS_DIRECT To: misformatted and direct-to-MX 2.6 TO_NO_BRKTS_NOTLIST To: misformatted and not a mailing list
On Sat, Aug 06, 2011 at 10:19:28AM -0400, Ryan Hughes wrote:
So, I had a crazy idea the other day:
Normally, when I talk to people about mesh networks, they assume that there is some central authority assigning IP addresses to nodes intelligently.
I was thinking, though, that I'd rather have it so that every node could have the same firmware, and you'd just throw the node up and it'd negotiate everything for itself, including its IP address.
Why reinvent the wheel? I would argue that using IPv6 stateless autoconfig
http://en.wikipedia.org/wiki/IPv6#Stateless_address_autoconfiguration_.28SLA...
and then working to provide a mechanism to support 'legacy' IPv4-only clients would be a beter solution than a lot of the hoops we have to jump through to support distributed dhcp cleanly.
My thought is every node runs radvd (ipv6 equivalent of dhcpd), and any ipv4 traffic will get tunneled over the v6 mesh network to the closest exit node with upstream IPv4 net access, which is where the DHCP server would run.
Why reinvent the wheel? I would argue that using IPv6 stateless
autoconfig
http://en.wikipedia.org/wiki/IPv6#Stateless_address_autoconfiguration_.28SLA...
and then working to provide a mechanism to support 'legacy' IPv4-only clients would be a beter solution than a lot of the hoops we have to jump through to support distributed dhcp cleanly.
I was looking into the idea of using IPv6-only on the inside of the network, but the consensus seems to be that this is a hard and unsolved problem.
Let's say that you are an IPv6-only client on the inside of the network. You want to view the website kittenwar.com. You look it up on DNS. Let's say that kittenwar.com only has an A record and not an AAAA record. If you don't have an IPv4 address, this A record is useless to you. The solution is this trick called DNS64. DNS64 is a proxy. If it sees that a site has only an A record, it will construct an AAAA record and return that for you, using the standard transformations of IPv4 addresses to IPv6 addresses.
Then, how does your IPv6 traffic get over to kittenwar.com, which is only listening on IPv4? The solution is a trick called NAT64, which nats your IPv6 traffic over to IPv4.
So the technology theoretically exists. But as of the time I was last doing the research, it was unstable and did not have a lot of development effort behind it.
It's not as simple as the problem of getting your IPv4 traffic out to an IPv6 address.
So, it's hoops either way. I was hoping that the distributed-dhcp path would be shorter.
But yeah, the problem is much simpler in IPv6-land, where there's autoconfiguration, and you can have as many IPv6 addresses as you need.
--Ryan
To dredge up an old thread:
On Sun, Aug 7, 2011 at 5:20 AM, Ryan Jud Hughes ryan@iheartryan.com wrote:
Why reinvent the wheel? I would argue that using IPv6 stateless
autoconfig
I was looking into the idea of using IPv6-only on the inside of the network, but the consensus seems to be that this is a hard and unsolved problem.
So the technology theoretically exists. But as of the time I was last doing the research, it was unstable and did not have a lot of development effort behind it.
totd (for your dns) + tayga (for your NAT64) worked for me a few months ago. For normal web browsing, ssh, IMAP, etc, it just works.
donald
Hi,
Now, what if the network is fractured and the same IP address gets assigned to a router (and thus is used as a prefix for that router's clients) on each side of the split? When the segments join up, we'll have multiple nodes with the same IP address and this will cause problems.
Yes. The lease times will be very short, so this type of problem should resolve itself quickly.
you are overlooking the fact that you can't be sure each gateway receives every DHCP packet even if you have a single network cell. On wireless you always have packet loss as opposed to wired networks. Therefore this approach won't be reliable. You can try things like arping nodes, etc but at the end of the day you will always hit the same wall: Just because nodeX did not receive a packet / can't reach nodeY you must not assume it does not exist.
But, what do I do about how the gateway business interferes with DHCP? Could I somehow have two DHCP servers serving the same interface? One that serves out IP addresses and one that deals only with gateways?
Why not simply disable the "gateway business" ? Or better, not enabling it - the gateway extension is disabled per default.
Regards, Marek
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/06/2011 10:19 AM, Ryan Hughes wrote:
I was thinking, though, that I'd rather have it so that every node could have the same firmware, and you'd just throw the node up and it'd negotiate everything for itself, including its IP address.
That is fairly easy to do. A given mesh runs the risk of two colliding IP addresses, but that is easy enough to evade if one picks a large enough potential address space.
So I was thinking: What if each node in the network was using batman-adv, and ran a DHCP client and a DHCP server? It'd try to get an address thru DHCP. If it failed, it'd choose an address at random from the network range. Then, any time someone threw up a new node in range, the new node would try to get an address, and it would succeed in getting an address from the first node.
That would indeed work. One could also write a small utility which pseudo-randomly chose an IP address from one of the RFC-1918 ranges (for example) and just configured itself with ifconfig. This is what I have been doing:
https://github.com/Sitwon/Byzantium/blob/master/control_panel/networkconfigu...
Multiple DHCP servers can serve the same, overlapping IP ranges. However, this depends on the DHCPOFFER and DHCPREQUEST being broadcast to the network. This is how we avoid having the same IP address assigned to multiple nodes -- DHCP servers overhear what was assigned to whom by other DHCP servers, and make a note to themselves not to assign that address themselves.
<makes a mental note>
I was unaware of this; I had assumed that, once a client had grabbed IP configuration information, it would simply ignore any other DHCPOFFERs.
So it seems that a "distributed" DHCP system could work.
For what it is worth, it seemed to work fairly well in small-scale experiments.
The problem is, doesn't Batman-adv munge the DHCP that flows though it, for its gateway logic? So that the DHCPREQUESTs are unicast? That's great for gateway logic. But I also want nodes to have IP addresses for internal communication.
I have not seen it do that in operation.
Is this idea just too crazy? Why?
It does not sound too crazy, but slightly overcomplicated for what you seem to want to use it for.
- --
The Doctor [412/724/301/703]
PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1 WWW: http://drwho.virtadpt.net/
A little booty house is good for the soul.
b.a.t.m.a.n@lists.open-mesh.org