sorry for late reply! Short answer: re-using globally valid ipv6 prefixes as interface prefixes should be avoided or done very carefully (due to bmx6 preliminary security concept). Long answer: In bmx6, propagating an OGM (routing update) is like a guarantee of the propagating node to all receiving nodes that promises: The propagating node itself and all next-hop nodes towards the initial originator of the OGM will route all packets to the initial originator if the packet has a destination address that matches any of the UHNAs given in the initial originator's description. You may find a more simple paragraph to say the same :-) In order to fulfill this guarantee two things must be enured: 1) UHNAs (as given in node descriptions) must be unique and unambiguous, thus allow a direct unambiguous mapping between a destination address and a bmx6 node. However, before you (your node) wants to give this routing guarantee (promise), it wants to be sure that its not supporting IP hijacking. Therefore: 2) Prevent IP hijacking: It must be possible to check if UHNAs announced by other nodes collide with already existing address allocations (also public ones). The easiest way to ensure this is to accept only UHNAs that match a given ULA prefix! Otherwise, how do you know if the primary address UHNA announced by node X is not the main IPv6 of google!? Above mentioned "bmx6 preliminary security concept" means that nodes are currently not strictly conforming to these rules. Actually, this probably requires to enforce even more restrictions: 1) Change AutoAddress generation: use globalID hash for ULA suffix instead of MAC nibbles 2) Let each node announce it's whitelist of UHNA-prefixs that are routed. Currently this whitelist is assumed hard-coded with fd66:66:66/48 being the only entry. And because no other node checks if advertised descripton UHNAs match any whitelisted UHNA prefix you can configure any interface prefix without trouble. But my idea is to change this. And then you should only configure interface prefixes that are whitelisted by many nodes of your mesh. In consequence, you would still be able to do what you propose. But the prefixes used for building your interface addresses should be: - rather static - maybe even part of your community license - preconfigured as whitelisted by all participating bmx6 nodes Hope what I say makes sens to you :-) a bit more inline: On 11/16/2013 09:31 PM, Gui Iribarren wrote: There is also a TT field, so like this: XXXX:XXXX:XXXX:TTII:MMMM:MMff:feMM:MMMM/64 where TT is: 0x00 for autogenerated interface addresses 0xFF for autogenerated fake-tunnel src addresses (see other thread) actually, this is not needed. BTW: in the current dev branch the 'II' field is already dropped and so are the globalPrefix options. But the 'TT' field is still there, but may also be dropped once proper symmetric two-way tunnels are supported :-) So the future one may look like this: XXXX:XXXX:XXXX:XXXX:NNNN:NNNN:NNNN:NNNN/128 where Xs = ipAutoPrefix nibbles (must be whitelisted UHNA prefixes Ns = Node GLobalID nibbles With a sophisticated whitelist format the postion of X and N fields could be configurable to gain more flexibility. For example to allow more entropy for Node GlobalID nibbles and have a /80 per node: XXXX:NNNN:NNNN:NNNN:NNNN:NNNN:NNNN::/80 Or for your use case you maybe looking for something like this: XXXX:XXXX:XXXX:XXXX:NNNN:NNNN:NNNN::/80 For the design of the whitelist format it would be interesting to know if the /80 is actually a relevant use case. Yes, backward compatibility is an issue. :-( I hope I can maintain backward compatibility for a while to facilitate the migration of existing deployments. But this just becomes relevant if the new concepts are all in place and "reasonable" tested. And for that any project that hasn't fully left its infantile stage is welcome to help. have a nice week :-)