[Olsr-dev] V4-via-v6, like in Babel?

[Rogge, Henning]

Hi,

the "auto-ll4" plugin uses a MAC based on IPv6 LL to set a random IPv4 of the 169.254.0.0/16 range on the interface. And (I think, long time since I wrote the code) it checks for collisions with the neighbors.

You still need one IPv4 for the originator, but it doesn't need to be a routable address I think (just globally unique). This is mandatory in OLSRv2 (as in the IETF RFC) because the originator for an IPv4 Hello/TC Message can only be 4 bytes.

Henning

-----Ursprüngliche Nachricht-----
Von: Linus Lüssing <(spam-protected)> 
Gesendet: Dienstag, 25. Oktober 2022 19:31
An: Rogge, Henning <(spam-protected)>
Cc: (spam-protected); Maciej Krüger <(spam-protected)>
Betreff: Re: AW: [Olsr-dev] V4-via-v6, like in Babel?

Hi Henning,

Ah, interesting, didn't know that OLSRv2 does this. Looks like I need to play more with it :-).

Does OLSRv2 then use these IPv4 link-local address as a mesh wide identifier / originator address? Or just locally for the next hop in an IPv4 route?

If the former, is there some duplicate address detection performed over the mesh? If I'm not mistaken this would otherwise be a birthday paradox and collisions would be probable for larger mesh networks:

#nodes -> probability for collision with 2^16 addresses
--------------
10 -> 0.0686%
25 -> 0.4568%
50 -> 1.85%
100 -> 7.28%
200 -> 26.21%
300 -> 49.61%
500 -> 85.17%

Regards, Linus


On Tue, Oct 25, 2022 at 05:56:46AM +0000, Rogge, Henning wrote:
> Hi,
> 
> I am not sure why OLSRv2 needs this...
> 
> By default, OLSRv2 generates an IPv4 linklocal IP for all mesh interfaces that have no IP, so "v4 over v4" should work out of the box.
> 
> Henning
> 
> -----Ursprüngliche Nachricht-----
> Von: Olsr-dev <(spam-protected)> Im Auftrag von Linus 
> Lüssing
> Gesendet: Freitag, 21. Oktober 2022 16:30
> An: (spam-protected)
> Cc: Maciej Krüger <(spam-protected)>
> Betreff: [Olsr-dev] V4-via-v6, like in Babel?
> 
> Hi,
> 
> Babeld and the Linux kernel got an interesting new feature which allows routing IPv4 packets via IPv6 next hops:
> 
> https://alioth-lists.debian.net/pipermail/babel-users/2022-March/00389
> 5.html
> https://datatracker.ietf.org/doc/html/rfc9229
> 
> I wanted to ask if somebody more familiar with the technical details of OLSR(v2) would know if a similiar approach would be doable with OLSR/OLSRv2, too.
> 
> Background: Next to batman-adv the Gluon firmware framework had added support for Babeld+l3roamd in 2018, but IPv6 only so far. While there were some (unfinished) experiments with XLAT in the past afterwards to get IPv4 working[0].
> 
> This year we had renwed interest to work on the Layer 3 parts in Gluon thanks to / from people from FunkFeuer Graz. They're working on getting OLSR running in Gluon [1][2][3][4].
> 
> For now development is focussing on getting OLSRv2 with IPv6 running 
> and merged. But one of the next steps will be to get OLSRv2 running 
> with IPv4 as well. And the new approach Babel offers sounds pretty 
> neat, which we would ideally like to use for both Babel and
> OLSRv2 in Gluon, if it works well.
> 
> Cheers, Linus
> 
> 
> [0]: https://github.com/freifunk-gluon/gluon/pull/1808
>      -> "introduce XLAT, native IPv4 for clients"
> [1]: https://github.com/freifunk-gluon/gluon/pull/2535
>      -> "OLSRDv2 Support: Initial Meshing"
> [2]: https://github.com/freifunk-gluon/gluon/pull/2418
>      -> "WIP: OLSR v1 & v2 support"
> [2]: https://github.com/freifunk-gluon/gluon/pull/2553
>      -> "Move common firewall rules to respective packages"
> [3]: https://github.com/freifunk-gluon/community-packages/pull/23
>      -> "ffgraz-ddhcpd: add package"
> 
> --
> Olsr-dev mailing list
> (spam-protected)
> https://lists.olsr.org/mailman/listinfo/olsr-dev