[Olsr-dev] IPv6 multi-homing and gateway advertisement

[Jeremy Lakeman]

On Wed, Oct 17, 2012 at 8:52 AM, Daniel <(spam-protected)> wrote:
> Hi!
>
> I recently wasted some thoughts on the ideal way to deploy IPv6 in olsr-routed
> mesh networks as I'm currently working on building a firmware for arig.org.il .
>
> Imho it makes most sense to use unique local addresses as defined in RFC 4193
> for local mesh clouds.
> Amir then pointed me to
> http://tools.ietf.org/html/draft-hain-ipv6-geo-addr-01
> And yes, that could make a lot of sense, I suggested to use the 20 or 24 bits
> prefix length as defined on
> http://tools.ietf.org/html/draft-hain-ipv6-geo-addr-01#page-7
> as part of the global ID of the ULA, thus deliberately violating
> http://tools.ietf.org/html/rfc4193#section-3.2.1

olsr works quite well on large mesh networks. Or at least at scales we
currently think of as large. But eventually it will break down at some
"OMG! That's friggen enormous" network scale.

The basic problem is that locally you have to know the exact topology
(or some equivalent approximation) to reach each host. But eventually
you'll consume all available bandwidth just talking about topology
changes.

I've wanted to experiment with a routing scheme that can deliver
packets at a very large scale based on some kind of geo-ip allocation.
It's nice to see that there's a pseudo standard address scheme
already. Otherwise I would have been tempted to create my own.

The draft you linked to suggested a 44-bit mapping from coordinates to
address prefix, giving ~6.4m sized subnet's. That's a bit too small
IMHO. I think you're right, that a 24-36 bit prefix is about the right
scale. We should pick a scale that allows an olsr-like routing
protocol to handle the lower level topology information no matter how
dense the network gets in each geo-ip based block. Or we need to scale
the ip block sizes based on the density of the network.

I also think the areas should overlap, so mobile devices near the
edges can claim an address in multiple subnets. That way they have
time to communicate address changes while they move around.

I think with olsr, each host should use the same host id for each
subnet they join on the same physical interface. Including a link
local (fe80::/64) address that should be used as the main device
address. This might also allow us to guess where a device is, and
blindly send them packets with different subnet id's.

Address allocations should be in the FC00::/7 private space, but we
could allocate them somewhere under FC00::/8 (which is currently
unused) instead of FD00::/8. Or just ask the IETF to allocate a
specific prefix for private geo-ip's. Either way we must make sure
that we don't overlap with link local addresses. Keeping them private
makes them easy to distinguish from publicly routeable HNA6
announcements from gateways to the internet.

> Anyway.
> My next step will be to abuse HNA6 to announce globally routed prefixes (e.g. a
> /64 as part of an /56 which can be obtained from a tunnel broker and some
> ISPs,also started to give /56 via DHCPv6). Instead of using NAT66 nodes can then
> be multi-homed in globally routed prefixes. For this to work, olsr need to
> automatically announce the (maybe dynamic) IPv6 prefix of an interface as HNA6
> and also be smart enough to understand that HNA6 announcements outside of the
> ULA range are actually router advertisements. (Instead of using setting an ::/0
> HNA6 which doesn't allow to advertise the globally routed prefix and thus either
> requires to use tunnel-broker or ISP obtained global IPv6 prefix(es) in the mesh
> or NAT66, which are both solutions I don't really like)
> So in the HNA6-gateway-prefix-hack-way every non-gateway node would be able to
> automatically choose an address within the IPv6 prefix of a nearby gateway and
> set the v6 default route to the ULA of the gateway.
> Also a bit dirty, but doesn't look to difficult to do and would combine the
> advantages of a convenient and consistent inside-mesh ULA addressing and yet
> having real global IPv6 routing without NAT66.... I saw that people previously
> thought about inter-operating OLSR and radvd, probably with similar goals.
> Forwarding ICMPv6 Router Advertisement messages through OLSR would definitely be
> more elegant...
> Any results? Experience worth sharing before I get started?
>
>
> Alternatively, I thought about modifying the SmartGateway feature to use
> L2TP(v3) instead of ipip (e.g. by using l2tpv3tun) thus allowing users of a
> v6-only ULA-addressed mesh to explicitly making a choice of a v4/v6 gateway
> which may offer DHCPv4 and DHCPv6 or RADV over an l2tp ethernet pseudo-wire.
> Obviously this variant is more resource-consuming on the gateways than using
> NIIT for IPv4 and either NAT66 or the method described above for IPv6 gateways.
>
>
> Maybe I'm just sitting in the fog and you folks figured out a perfect way to do
> this long ago. If so, please let me know :)
>
>
> Cheers
>
>
> Daniel
>
> --
> Olsr-dev mailing list
> (spam-protected)
> https://lists.olsr.org/mailman/listinfo/olsr-dev