Hi all,
Thank you all for your comments!
Alex and Julien: thanks for clarifications on 16ng.
Stephane and Brian Carpenter: I used the term .local with
no particular reason. If recent advances showed that it is
unnecessary. That's OK for me. I'm not even sure if my
proposal needs to be "local". I can also reach other subnets
in theory (if my host has learned the list of neighboring
subnets).
I also take note of RFC4541. Thanks.
But I still don't see why I would send a multicast query
if I know the destination's unicast address. Sending the DNS
query directly to the destination may be useful. For example,
the host may have already resolved the destination's
MAC address (through multicast). But the user is trying many
different names... (for example).
My question to Paul Vixie:
On Wed, 2007-01-10 at 17:58 +0000, Paul Vixie wrote:
> > ...
> > 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.
Is this an important limitation? (I'm asking the question)
> and you'll have to cope with hash
> collisions, however improbable they may be.
Fortunately, there is no problem with that. If a given name-based
address was accidentally configured the query will be silently
dropped.
> > 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.
I have no problem with that.
Thanks
pars
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
