> As a result, it seems fairly effective in ensuring > that multicast does not wake up unnecessary > neighbors. It does not solve all problems -- if > you were to run LLMNR over it you would still > be sending to every node, because only one > multicast address is used. But then again, > I'm not sure how big practical problem this > is. I hope the providers are not setting up > their 802.16 networks so that people can > find printer.local in the Tokyo subnet...
and this would be bad in what way? :) > Anyway, if we think of the hash approach independently > of your 802.16 use case, I think there are still several > significant problems. As others have mentioned, you > still need something that allows ND to work, and it, > in turn is based on multicast at IP level. Perhaps > more fundamentally, I think a local unmanaged naming > system should be able to live with collisions. As your > scheme combines the name space to the IP space > this becomes very difficult. For starters, to allow > multiple similar names, you would have to disable > DAD and change ND, and I suspect it would not work > with current TCP and applications. Also, there > are operational issues such as inability to search > except for exact match. DISCOVER works with namespace collisions. fuzzy matching -after- the collision is detected requires more than just the FQDN and address. When we did the original work on this (a decade ago) in the TBDS project, we used a local crypto key as a third discriminator. Neither DISCOVER or TBDS is v6-specific. > > Jari > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------