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

[Teco Boot]

Interesting subject !

Op 17 okt. 2012, om 02:51 heeft Jeremy Lakeman het volgende geschreven:

> 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 .
This keeps me busy for several years now. Still thinking (and writing Internet Drafts :-). 

>> 
>> 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.
For OMG scale networks, we need some form of route aggregation. We know how 
to scale backbones. The router connected to the backbone is the border router,
this one would receive a prefix (say /48, /56). If nodes downstream this
border router configures addresses from this prefix, they are globally reachable.
We just need to fix multi-homing and dynamic renumbering. This is one outcome
or the IRTF Routing Reasearch Group. Not everybody agrees. I do.

> 
> 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.
This would be difficult and take a long time. 

> Either way we must make sure
> that we don't overlap with link local addresses.
LL cannot be routed. ULA would be a better choice..

> Keeping them private
> makes them easy to distinguish from publicly routeable HNA6
> announcements from gateways to the internet.
Yes.

For small experiments, I don't think there is a problem with ULAs. There
are 56 bits for the prefix in the fd::/8 block. So with 36-bit for location,
there are 20 bits for quasi-random well-known geo-address prefix.
So instead of the 1::/4 we could use for example fdf9:a96e:f400::/28. Generated
with hash over this text, while typing.

> 
>> 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)
This is what my BRDP proposal does. It is written as extension on RA. Can be done
with OLSR messages (or whatever IGP) also.
The BRDP idea is somewhat old, I recently picked it up again. Now I propose it as a
solution for IETF Homenet WG.

For experiments in OLSR, the SmartGateway plugin could be updated. Ferry is working 
on multiple tunnels and adding ip rules / tables to direct traffic into the right
tunnel. For BRDP, tunnels are not needed. Traffic for destinations outside the mesh
shall be forwarded towards the border router that "owns" the source address prefix.
With Linux, this is not that difficult to do.

See http://www.ietf.org/internet-drafts/draft-boot-homenet-brdp-00.txt for details.
Any feedback is welcome.


>> 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?
Because there are more options on how to implement this, let's take the effort
to sketch the raw design. Please check my BRDP draft, maybe also earlier work.
Pointer: http://www.inf-net.nl/brdp.html
I'm happy to cooperate and bring this work towards IETF. I'm in Atlanta and probably
present in Homenet WG. Homenet != MANET and != Mesh. But Homenet has to support
multi-hop topologies and should support multi-homing and auto-configuring. We have 
some experience how to do that. 

>> 
>> 
>> 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 :)
Jeremy, can we have a chat? GMT+2 around here.

Teco

>> 
>> 
>> Cheers
>> 
>> 
>> Daniel
>> 
>> --
>> Olsr-dev mailing list
>> (spam-protected)
>> https://lists.olsr.org/mailman/listinfo/olsr-dev
> 
> -- 
> Olsr-dev mailing list
> (spam-protected)
> https://lists.olsr.org/mailman/listinfo/olsr-dev