dangowrt
commented
4 years ago somehow relaying DHCPv6 inside the tunnel was brought up as a possible solution, but that may sound easier than it is, as on the gateway side, the routes have to be added to the tunnel interfaces created by bmx7.
But this provides a possible path reusing the existing delegation mechanisms the protocol suggests.
odhcp6c would need a new parameter to specify a unicast address. and odhcpd would need a way know which tunnel interface a relayed-dhcpv6 request belongs to.
It would also be difficult to have the same prefix assigned to many nodes -- a quite common situation if many bmx7 nodes are serving clients inside the same layer-2 domain.
Hence, maybe the stateless autotun approach @axn had previously come up with may be the only feasible way to provide topological prefix delegation in bmx7.
Similar to how DHCPv6 allows to requests preferably static prefixes or privacy/dynamic prefixes (and commercial ISPs started to expose that option in the web-ui of their routers, eg. T-Com Speedport), it'd be nice if in the long run we can also have it both in the bmx7 world.
So imho we could still start with the stateless autotun approach at first and then add delegation of privacy prefixes on top of that at a later stage.
What do you think?
currently there is no feasible way to distribute a uplink gateways ipv6 subnets to clients. we need a plugin to run on a gw and all client nodes requiring ipv6.
the gw should announce its available ip6 subnets, clients can request those, at random or based on a setting. the gw tracks distributed subnets to avoid doubled assignment's. once the client has its own ipv6 subnet they can offer addresses to connected end user devices.
this issue is meant as a draft, please comment for further improvements and clarifications