> 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
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
