28 Apr
2017
28 Apr
'17
2:11 a.m.
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(a)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(a)tnode.com
<javascript:_e(%7B%7D,'cvml','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
--
http://mitar.tnode.com/
https://twitter.com/mitar_m
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(a)tnode.com
<javascript:_e(%7B%7D,'cvml','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(a)labitat.dk
<javascript:_e(%7B%7D,'cvml','juul@labitat.dk');>> wrote:
>>
>>>
>>>
>>> On Thu, Apr 27, 2017 at 1:22 PM, Mitar <mitar(a)tnode.com
<javascript:_e(%7B%7D,'cvml','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