IPv6/IPv6Concepts

At the time of this writing there is no clear concept about how to implement IPv6 inside mesh networks. There are some challenges to solve

* What addresses to use inside the mesh? ULA or globally routable?
* how do we realize the gateways to the internet?
* How to setup /64 prefixes on the single nodes to be served to clients in a way that no collisions happen?

Multiple possibilities how it can be done exist. This page tries to list these possible configurations.

Mesh networks that use OLSR

Concept 1 - Use ULA adresses and 1:1 Nat (NPTv6 or Map66) at the gateways

Use ULA prefix inside the mesh, e.g. fdca:ffee:babe::/48. Every node gets at least one /64 from this space and uses an IPv6 from this /64 for the mesh interface(s). The other IPs in this net can be used to serve to connected clients using radvd (see below on how to generate these /64). Also announce this IPv6-network as olsrd Hna6. On every gateway use NPTv6 (http://git.universe-factory.net/NPTv6) or map66 (http://sourceforge.net/projects/map66/) to 1:1 map these ULA addresses to the external addresses

Pro

+ relatively easy to setup
+ internal addressing stays the same regardless of the gateway (no renumbering needed when one gateway would be used and ipv6-addresses from that gateways network would be used inside the mesh

Contra

- 1:1 nat breaks end-to-end connectivity
- Operating systems prefer ipv4 over the ULA-address they got from radvd by default (See NPTv6 README)
- Gateway needs at least a /48 network (to map a /16 ipv6 network)
- Reachable from the outside address only via the gateway that is the current defaultroute

Concept 2 - Use global prefix inside the mesh

Use a global prefix in the mesh. It is easy to get a /48 from tunnel providers like tunnelbroker.net or sixxs.net. It is also possible to use 6to4, but because this is coupled to the external IPv4 address i would not recommend this (IPv4 changes -> Prefix changes).

Pro

+ Easy to implement
+ direct end-to-end connection
+ All nodes inside the mesh are always reachable from the same address from the outside

Contra

- Only one gateway per mesh possible (Single point of failure, doesn't fit with our ideal of decentralisation)
- If the prefix of the gateway changes the whole mesh needs to be renumbered

For redundancy and to avoid prefix changes the best option would be to use provider independant (PI) IPv6 space and your own ASN and announce that network via BGP to the internet (tunnelbroker would even provide BGP peering and transit for free). But getting PI/ASN usually means you have to pay for using these resources, also the administration overhead is bigger compared to using a static tunnel.

Concept 3 - Auto-IPv6

Auto-IPv6 (https://github.com/stargieg/packages-pberg/tree/c4d4a19afd0c2be7bfa382b4eb6c645754fc45f4/utils/auto-ipv6) is a set of scripts for openwrt which have two functions:

1) It can create a 6to4 tunnel on nodes that have their own IPv4 uplink. Note: It is also possible to not use that feature and use a ipv6 net from a tunnel provider like tunnelbroker or sixxs instead. This needs to be announced by olsrd as ::/0.
2) Nodes start up using ULA adresses. But when a gateway announcement is received auto-ipv6 automatically configures a nodes IPv6 address/network so that it fits to the prefix of the received default gateway also sets up radvd to serve IPv6 addresses from this prefix (which needs to be a /64) to clients. In the current implementation it shuffles the 4th part of the IPv6 address which can result in collisions.

Pros

+ Multiple Gateways are possible
+ No renumbering is needed when gateway prefixes change

Contra

- the external IPv6 address of clients changes when the default gateway changes
- Switching from one to another gateway takes some time. There is not much we can do about this because of the HNAValiditytime of olsrd. Switching is faster if a new ::/0 HNA is received by a gateway closer to you (about 1 minute) and slower if a gateway that was closer to you disappears and you need to switch to a more distant gateway (with HNAValiditytime of 300 which is the default about 6 minutes)
- After a new gateway is received it will restart olsrd (currently both IPv4 and IPv6), which will result in losing connectivity for a short period of time until the routing table is rebuild.

Concept 4 - Use auto-ipv6 but only have one gateway in the mesh

Pro

+ External IPv6 usually stays the same (as long as it doesn't change on the gateway)
+ If the prefix changes on the gateway all nodes in the mesh will automatically switch to this new prefix.
+ End-to-end connectivity
+ No olsr restarts required if there is only one gateway

Contra

- centralized

Howto generate /64s on the nodes

Lets assume we have a mesh running with IPv4 that uses a /16 network, which is quite common for freifunk (although it would be advisable to use smaller prefixes) and we want to add at least one /64 IPv6 net to every node. Also assume we have a /48 IPv6 network we can use. That means that for every IPv4 we have exactly one /64 we can use (65536 in total).

Option 1

Shuffle the 4th part of the IPv6 address. The more nodes are in the mesh the more likely it becomes that we run into address conflicts, so a mechanism should be added to check for a conflict and if it exists shuffle again until a free prefix is found).

Option 2

Generate the 4th part of the IPv6-network from the last two octets of the IPv4 address, e.g. IPv4 interface address is 10.0.0.101, then we would use fdca:ffee:0ffa:0065::/64 as ULA adress/network (note how 00 65 translates to 0 101 in decimal notation. One problem with this approach is that we can only use one IPv6 /64 network per IPv4 address. So how would we setup another net for interfaces that are not part of the mesh, e.g. lan which uses an IPv4 address from RFC1918 space and is natted?

More ideas / Papers

* Wakikawa et al., Global connectivity for IPv6 Mobile Ad Hoc Networks
* Adjih et al., Address autoconfiguration in Optimized Link State Routing Protocol