> ...
> These problems make me think that dot-local usage is not as general
> as it should be in IPv6. What about this approach?
>
> It works exactly as multicast DNS, except that there is no multicast.
>
> 1. Let the responder's DNS name be "johnsmith.local". The responder
> configures a name-based link-local IPv6 address:
>
> link-local subnet prefix | 64bithash("johnsmith.local")
>
> where hash is SHA1, and '|' means concatenation. It can be noted
> that 64bithash("johnsmith.local") is the IPv6 interface ID.
> The link-local subnet prefix is constant and well-known.
you'll also have to cope with networks that aren't using EUI64 or for that
matter aren't using a 64-bit netmask. and you'll have to cope with hash
collisions, however improbable they may be.
> 2. When the initiator user (or application) enters the name
> johnsmith.local, the DNS request is sent to the above address,
> instead of being multicast.
>
> Am I missing something?
L2 broadcast will have to work in order to support ARP. if your L2 does not
support broadcast at all then i don't know what to suggest beyond some kind
of distinguished destination address that operates a location brokerage for
other services. if your L2 supports broadcast but at significant power cost
then i suggest we revive bmanning's old DNS DISCOVER proposal.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
