Pars Mutaf wrote:
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.
I agree. I'm not sure whether that draft allows this behaviour or not
(send direct DNS message instead of multicast). It can be suggested though.
As an example, we can take WiMax (IPv6 over WiMax is being
standardized by the 16ng WG).
They look mostly at 802.16 less at WiMax which is somehow normal to me
since WiMax are moving more than 802.16.
In 16ng, the access router has a list of all nodes.
Not sure which entity you mention? Not necessarily WiMax. I think any
router has a list of its neighbours in NC.
This corresponds to what you call a central node. DAD (duplicate
address detection) is achieved using unicast.
Not sure which document you refer to. The first DADing NS is sent to
solicited-node multicast address (by rfc2462), and not to unicast address.
Some documents in 16ng talk 'Relay DAD' which would maintain a list and
then unicast a NS; but other signals in WiMax forum seem to indicate
deprecating the use of 'Relay ND' for rfc4541 instead.
This is work in progress. As for neighbor discovery, I agree that it
is more reliable over L2 multicast.
Yes, more reliable and mandatory. Actually IPv6 ND doesn't work at all
over a link-layer that isn't doing multicast link-layer addresses.
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?
Because not scalable? Ie memory can overflow if too many nodes?
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.
Err...? If I want to encode my private key and my name into my IPv6
64bits would this work?
Alex
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
