[Battlemesh] ipv6 prefix delegation in layer 3 mesh networks

Philipp Borgers borgers at mi.fu-berlin.de
Thu Feb 11 20:12:52 CET 2016

On Thu, Feb 11, 2016 at 04:12:16PM +0100, Juliusz Chroboczek wrote:
> >> How do the other nodes distinguish between prefixes that are made
> >> available for PD, and prefixes that have been delegated and assigned to
> >> individual nodes (that don't run a DHCPv6-PD server)?
> > I don't think I understand your question. I would say the other nodes
> > don't care.
> If I understand Philipp's scheme right, the DHCPv6 relay discovers the
> address of the DHCPv6-PD server by snooping on the routing protocol.  So
> it needs to be able to distinguish an HNA that announces a prefix
> available for delegation (announced by a node running a DHCPv6-PD server)
> from an HNA announced by a DHCPv6-PD client (which is not willing to
> provide further sub-delegations).
> So how do you distinguish?  By looking at the prefix length?

First we thought that we should extend the routing protocol and announce the
prefix delegation as a kind of service. Only the gateway that owns the prefix
could announce prefix delegation service. Maybe we could create a new message
type in the protocol or extend something like HNA messages with one bit of
information about the willingnes of delegation.

We think we could use the fact that a gateway willing to delegate a prefix
will also announce a default route (::/0). If a nodes detects a gateway with
local attached network and default route it's safe to assume this gateway will
delegate the prefix.

We may send some unicast messages to gateways that don't delegate prefixes or
don't have prefixes to delegate anymore. I think we can assume that the amount
of unnecessary messages is quite low.

Maybe we can also use the prefix length. If we search in the set of prefixes for
the biggest prefix we can maybe assume the node will delegate the prefix.

Thanks for the feedback so far!

> _______________________________________________
> Battlemesh mailing list
> Battlemesh at ml.ninux.org
> http://ml.ninux.org/mailman/listinfo/battlemesh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://ml.ninux.org/pipermail/battlemesh/attachments/20160211/ac65a989/attachment-0001.sig>

More information about the Battlemesh mailing list