[Battlemesh] ipv6 prefix delegation in layer 3 mesh networks

Henning Rogge hrogge at gmail.com
Thu Feb 11 14:28:43 CET 2016


we need something like HNCP (Homenet Configuration Protocol)...

It does all the address and prefix distribution.


I had a funny idea how we could use the current HNCP for our mesh
networks without changing too much...

we increase the timeout for a "link" between two HNCP nodes to 1
hour... and when one link times out, we time out every link where the
timeout is already 30 minutes old.

This way we aggregate broken links and don't add too much state...
should work for Wifi networks.

What do you think, maybe something to test?


On Thu, Feb 11, 2016 at 2:15 PM, Philipp Borgers
<borgers at mi.fu-berlin.de> wrote:
> Hi,
> in our local wireless community network we would like to properly deploy IPv6 on
> top of a layer 3 routing protocol such as OLSRv2, babel, etc..
> We spent some time reflecting on how to achieve our goal. I would like
> to share our thoughts with you and would like to ask you for your feedback.
> Our main goal is to have one ore more public IPv6 prefixes in the mesh network.
> The problem domain can be split in two larger problems:
> 1) How do we distribute the ipv6 public prefix from a gateway node to nodes in
> the network? The problem here is that we can't just use DHCPv6 or NDP because we
> don't have one big layer-2-network.
> 2) How do we guarantee that packets with a specific source address get routed
> via the gateway the address originated from? The problem is that a gateway or
> upstream ISP would possibly drop outbound packages that do not have a src ip
> from the gateway prefix. This makes sense to mitigate e.g. DDoS attacks based
> on source address spoofing.
> To my knowledge, the later problem is solved by source specific routing
> implemented in layer 3 routing daemons such as OLSRv2 or babel(s).
> The proper distribution/delegation of IPv6 prefixes still remains a problem.
> I suggest that we use a combination of IPv6 prefix delegation and DHCPv6 relays
> to delegate prefixes from the gateway to the nodes (and clients of the node).
> I assume that we can establish basic connectivity between nodes in the mesh
> network by using ULA prefixes [1] and a routing daemon that uses these
> addresses for establishing a mesh network.
> A gateway that has a prefix to delegate starts a DHCPv6 server. The server is
> reachable by other nodes via the ULA address [1]. In addition, the server can be
> reached by other nodes via a public IPv6 address that is part of the prefix.
> A gateway that wants to delegate prefixes announces the prefix to the other
> nodes (think of HNAs or local attached networks).
> A node that wants to use one or more prefixes gets a list of available prefixes
> and the responsible gateway ips through the routing daemon. The node can use the
> gateway ips to configure a list of destination addresses for its local DHCPv6
> relay. [2]
> A node that wants to request a prefix for local delegation can send a prefix
> delegation request to the local DHCPv6 relay. The relay will forward the
> delegation request via unicast/multicast to gateways/DHCPv6 servers responsible
> for a prefix.
> Once a node received a prefix, the prefix can be destributed to clients e.g. via
> NDP/SLAAC (stateless auto address configuration).
> A node that received a prefix announces the prefix in the layer 3 mesh. The node
> and all clients will be reachable through the announced prefix.
> A node will only ask gateways for a prefix if they announce a default route
> (::/0).
> To reduce complexity of the setup we could also push for an extension of the
> dhcpv6 client behaivour as described in section 18.1 of the DHCPv6 RFC [3].
> This would make the relay agent on the node obsolete because the node can
> send a DHCPv6 client request directly to the server on the gateway.
> We will try to implement this idea in the next month in a test bed. Before we
> start to implement the idea we would love to get some feedback from you.
> Best Philipp
> [1] https://tools.ietf.org/html/rfc4193
> [2] https://tools.ietf.org/html/rfc3315#section-20
> [3] https://tools.ietf.org/html/rfc3315#section-18.1
> _______________________________________________
> Battlemesh mailing list
> Battlemesh at ml.ninux.org
> http://ml.ninux.org/mailman/listinfo/battlemesh

More information about the Battlemesh mailing list