Yes dhcp now. Each node is assigned a /26 at birth by makenode. It uses the first ip for itself and the next four for extender nodes then hands out the rest to clients on short leases. If we want ipv6 then we could get the nodes to self-assign a random small subnet within a specified larger subnet. We will then want to use dhcpv6 to hand out ips to clients for a few reasons but a big one is that most operating systems embed their MAC address in their self-assigned ipv6 address which would turn the mesh into a huge tracking network just by traceroute'ing continuously to a predictable set of ips for a know MAC for e.g. someone's phone. Windows is the only major OS that "does it right" and uses the alternate strategy for ipv6 self-assignment which was added to the standars later, namely "randomly generate". Linux folks are being stubborn and want to stick to the default that is specified in the standars as the default. This is terrible for privacy. Using dhcpv6 means we can ensure that client MAC addresses are not embedded in assigned IPs

On Thursday, April 27, 2017, Jehan Tremback <jehan.tremback@gmail.com> wrote:
Oops, yea not link local, but random. How do client devices get ipv4 addresses now? Not dhcp, right?

On Thu, Apr 27, 2017 at 8:44 PM, Mitar <mitar@tnode.com> wrote:
Hi!

Ah, for nodes. Yes, nodes could have automatic IPv6 addresses (and not
even link-local, but global).

For clients is trickier.

But we could do some automatic IPv6 address subnets for nodes. :-)


Mitar

> Well, I'm not an expert on all the details, but I imagine we'd generate
> them randomly during makenode (or whenever). Then routes to addresses would
> be propagated by babel in the same way that ipv4 addresses are now. I'm not
> sure if the exit server would need an ipv6 address or if it would be good
> to switch existing nodes over.
>
> -Jehan
>
> On Thu, Apr 27, 2017 at 7:50 PM, Mitar <mitar@tnode.com> wrote:
>
>> Hi!
>>
>> I was asking for the "IPv6 randomly generated link-local
>> addresses" idea. How would that route?
>>
>>
>> Mitar
>>
>>>> And how would you route that over L3 network?
>>>
>>> Off the top of my head:
>>>
>>> - Packet headed somewhere on the internet with an ipv4 address comes
>> from a
>>> client device to the home node.
>>> - Home node pops that packet into an ipv6 packet bearing the ipv6 address
>>> of the exit server which is then routed over the mesh network
>>> - Exit server takes the ipv4 packet out and does NAT on it (switches the
>>> source address to public IP) and sends it out to the internet.
>>> - Response from internet comes back to exit server, the exit server does
>>> NAT again (switches the destination address to private IP)
>>> - Exit server puts the packet into an ipv6 packet with the ipv6 address
>> of
>>> the home node and sends it onto the mesh (it needs to have kept track of
>>> the ipv6 address)
>>> - Home node receives the ipv6 packet, takes the ipv4 packet out and sends
>>> it to the client.
>>>
>>> I'm not an expert, so there might be some issues with this. Here's an RFC
>>> which might be similar:
>>>
>>> https://tools.ietf.org/html/rfc7040
>>>
>>> On Thu, Apr 27, 2017 at 1:28 PM, Marc Juul <juul@labitat.dk> wrote:
>>>
>>>>
>>>>
>>>> On Thu, Apr 27, 2017 at 1:22 PM, Mitar <mitar@tnode.com> wrote:
>>>>
>>>>> Hi!
>>>>>
>>>>>> IMO, we should put everything on ipv6 randomly generated link-local
>>>>>> addresses to avoid the whole makenode centralized IP assignment
>>>>> business.
>>>>>
>>>>> And how would you route that over L3 network?
>>>>>
>>>>> It would work over L2 Batman network. But not over L3.
>>>>>
>>>>> Have you looked into AHCP:
>>>>>
>>>>> https://www.irif.fr/~jch/software/ahcp/
>>>>
>>>>
>>>> Ssssh! Why did you have to tell them about AHCP?
>>>>
>>>> ... *OBLIVIATE!*
>>>>
>>>> --
>>>> marc/juul
>>>>
>>>
>>
>> --
>> http://mitar.tnode.com/
>> https://twitter.com/mitar_m
>>
>

--
http://mitar.tnode.com/
https://twitter.com/mitar_m