[B.A.T.M.A.N.] "Distributed" DHCP vs gateway

[B.A.T.M.A.N.] "Distributed" DHCP vs gateway

[Ryan Hughes]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2757 bytes --]

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

[-- Attachment #2: SpamAssassinReport.txt --]
[-- Type: text/plain, Size: 1347 bytes --]

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

Re: [B.A.T.M.A.N.] "Distributed" DHCP vs gateway

[Troy Benjegerdes]

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_.28SLAAC.29

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.

Re: [B.A.T.M.A.N.] "Distributed" DHCP vs gateway

[Ryan Jud Hughes]

> Why reinvent the wheel? I would argue that using IPv6 stateless
autoconfig
> 
>
http://en.wikipedia.org/wiki/IPv6#Stateless_address_autoconfiguration_.28SLAAC.29
> 
> 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

Re: [B.A.T.M.A.N.] "Distributed" DHCP vs gateway

[Donald Gordon]

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

Re: [B.A.T.M.A.N.] "Distributed" DHCP vs gateway

[Marek Lindner]

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

Re: [B.A.T.M.A.N.] "Distributed" DHCP vs gateway

[The Doctor]

-----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/networkconfiguration.py#L321

> 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.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk5ANeIACgkQO9j/K4B7F8EQXwCg37mCXI/xCJtFiTvSa9TreR5w
C5oAn0aiHDrSNc5/Zvl/MMmRafP3Tx23
=GPyU
-----END PGP SIGNATURE-----