Proposed optimization to multicast DNS

["Brian Zill" <[e-mail]>]

I'd like to propose the following optimization to the multicast DNS
draft.  It is only applicable to IPv6, since it takes advantage of the
larger multicast address space available in IPv6.

The current version of the draft (draft-ietf-dnsext-mdns-01.txt) uses a
single well-known link-local multicast address for all queries.  This
causes all responders to perform some packet processing on each query,
even though in most cases this processing is merely to determine that
the packet should be dropped (i.e. the query isn't for a record
belonging to that responder).

This is an analogous situation to IP address resolution, where queries
are sent to discover a node's link-layer address.  In IPv4 over
Ethernet, the ARP protocol uses broadcast packets (which is equivalent
to using a single multicast address that everyone listens to).  In IPv6,
however, Neighbor Discovery uses a more efficient scheme where nodes
listen on a multicast address that is derived from their IP address --
this is the "solicited node multicast address".  By basing the address
to query on the very thing that is being queried, only those nodes that
can actually respond to that query are likely to ever receive the
packet.

I propose something similar for multicast DNS.  All IPv6 responders
should listen to multicast queries on a "solicited name multicast
address" instead of a single well-known multicast address.  They derive
their solicited name multicast address(es) by combining a 104-bit
well-known link-local multicast prefix with the 24-bit result of a hash
over the first portion of the name of the record(s) for which they are
authoritative.  Senders wishing to issue a query for a given record
would first generate the solicited name multicast address corresponding
to the record they wish to lookup.  Then they would send the query to
that address.  Only those nodes listening to that particular multicast
address would receive the packet, thus reducing significantly the amount
of packet processing required by nodes participating in multicast DNS.

Open issues:

Size of multicast prefix and hash result.  I chose 104 and 24,
respectively, simply because those are the lengths used for solicited
node multicast addresses.  A smaller hash result would increase the
likelihood of collisions, but the smaller address range might be more
palatable to IANA.  The choice of hash function might also figure in
here.

What hash function to use?  Any half-way reasonable hash function would
do, so it might be wise to use a hash function that all IPv6
implementations are required to have anyway.  But MD5 and SHA-1 both
seem a little overkill for this purpose.  The internet checksum isn't
great, and only yields 16 bits, but the code is present everywhere.
There are plenty of other possibilities.

Comments?
--Brian


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