On Wed, 2007-01-10 at 08:15 -0500, James Carlson wrote:
> Pars Mutaf writes:
> > Dot-local DNS is also very useful in MANETs. However, you have
> > to flood the network to resolve a name. This consumes bandwidth
> > and energy in the whole network.
>
> It isn't just multicast DNS that depends on the use of multicast --
> there are many protocols (including neighbor discovery) that will
> either fail to work properly if multicast is outlawed or will need
> modifications or limitations.
>
> This sounds like a syntax error to me. The system in question
> apparently wants to use what are effectively point-to-point links but
> is instead modeling as a crippled broadcast-type network.
>
> I say "apparently," because the proposal below wouldn't work unless
> there's some central node involved. As part of resolving that IPv6
> link-local address to an L2 address, nodes will send multicast
> neighbor solicitations. The apparent fact that this doesn't wake
> everyone up means that the network is already partitioned.
>
> Given that use of multicast typically isn't a privileged operation,
> how does that central node stop someone from draining everyone else's
> batteries anyway, even if this one protocol is fixed?
This threat is probably another good reason for not allowing
multicast.
>From an abstract point of view (hoping to answer all your concerns
above): if we already know the destination's unicast address, then
we should not send a multicast query. We should send a unicast query.
This is my proposal. This is the conservative approach IMHO.
As an example, we can take WiMax (IPv6 over WiMax is being standardized
by the 16ng WG). In 16ng, the access router has a list of all nodes.
This corresponds to what you call a central node. DAD
(duplicate address detection) is achieved
using unicast. This is work in progress. As for neighbor discovery,
I agree that it is more reliable over L2 multicast. I hope that the
access router can use it to recover from loss of state, but not
during normal operation (because it is costly). 16ng WG will decide.
Now one can say: if the WiMax AR knows knows everything, why not
register the localname->address bindings also to the AR?
My answer is that installing DNS in a router is going to far.
I'm proposing a solution for not doing this. The AR speaks IPv6,
so lets encode the names into IPv6 addresses.
But again, IMHO, from an abstract point of view, unicast will always
be the conservative approach. I.e. not only for WiMax.
> > 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.
> [...]
> > http://www.freewebs.com/pmutaf/humid.html
>
> So, the proposal is that if the hash collides for different names,
> then "johnsmith.local" must rename himself, right?
Right. Please let me know if you see a problem with this.
Thanks!
pars
>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
