Subject: RE: comments on mnds-00

From: "Dave Thaler" <[email-masked]>
Date: Tue, 27 Mar 2001 16:13:00 -0800

Erik,
I'll reply to one of your comments and leave the others
for others to respond to.

> >The responder MUST set the Hop Limit
> >field in IPv6 header and TTL field in IPv4 header of all responses to
> >the multicast DNS query to 255. The sender MUST verify that the Hop
> >Limit field in IPv6 header and TTL field in IPv4 header of=20
> each response
> >to the multicast DNS query is set to 255. If it is not, then=20
> sender MUST
> >ignore such response.
>=20
> Shouldn't IPv6 hop count / IPv4 TTL be 1 for link-local multicast dns?
> If this is a 'clever trick' which will cause listeners to=20
> drop messages
> after they've traversed a single router (they will always be=20
> less than=20
> 255 in this case), I claim this is not a good idea.  A link-local=20
> protocol shouldn't be routed at all:  We choose an address we specify=20
> routers must not forward, and we send with hop count/ttl =3D 1=20
> to further=20
> reduce this possibility.

This rule is basically stolen from RFC 2461 which solves the same
problem the same way.  It's true that what we really want is
to ensure that a packet we got was not routed.  The TTL=3D255 method
is safe, and solves the problem regardless of how we got the message
(i.e. via either unicast or multicast).  An equivalent method
would probably be to verify that the destination address
was the link-scoped address (and not one of our unicast
addresses, for example).

In an attempt to avoid the debate over which mechanism is best, the=20
draft just copied the one that is already at Draft Standard for=20
another link-local protocol (ND).

-Dave

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.