Subject: RE: Proposed optimization to multicast DNS

From: "Brian Zill" <[email-masked]>
Date: Tue, 17 Jul 2001 05:34:34 -0700

As Itojun Hagino and Matt Crawford point out, Matt's ICMP name lookups
draft (draft-ietf-ipngwg-icmp-name-lookups-07.txt) performs lookups
using multicast addresses in essentially the same manner I proposed for
mdns below.  Even better, blatantly copying the details of Matt's
solution resolves the open issues of which particular hash function and
multicast prefix to use in forming the address (and also lessens the
number of multicast addresses a node implementing both drafts need
listen on).  Also, Matt's solution addresses the issue raised by David
Terrell (answer: lowercase the alphabetic characters before hashing).

Thanks Matt.  I've proposed this solution to the mdns draft authors.
--Brian

>-----Original Message-----
>From: Brian Zill=20
>Sent: Wednesday, 11 July, 2001 22:52
>To: [email-masked]
>Subject: Proposed optimization to multicast DNS
>
>
>I'd like to propose the following optimization to the=20
>multicast DNS draft.  It is only applicable to IPv6, since it=20
>takes advantage of the larger multicast address space=20
>available in IPv6.
>
>The current version of the draft=20
>(draft-ietf-dnsext-mdns-01.txt) uses a single well-known=20
>link-local multicast address for all queries.  This causes all=20
>responders to perform some packet processing on each query,=20
>even though in most cases this processing is merely to=20
>determine that the packet should be dropped (i.e. the query=20
>isn't for a record belonging to that responder).
>
>This is an analogous situation to IP address resolution, where=20
>queries are sent to discover a node's link-layer address.  In=20
>IPv4 over Ethernet, the ARP protocol uses broadcast packets=20
>(which is equivalent to using a single multicast address that=20
>everyone listens to).  In IPv6, however, Neighbor Discovery=20
>uses a more efficient scheme where nodes listen on a multicast=20
>address that is derived from their IP address -- this is the=20
>"solicited node multicast address".  By basing the address to=20
>query on the very thing that is being queried, only those=20
>nodes that can actually respond to that query are likely to=20
>ever receive the packet.
>
>I propose something similar for multicast DNS.  All IPv6=20
>responders should listen to multicast queries on a "solicited=20
>name multicast address" instead of a single well-known=20
>multicast address.  They derive their solicited name multicast=20
>address(es) by combining a 104-bit well-known link-local=20
>multicast prefix with the 24-bit result of a hash over the=20
>first portion of the name of the record(s) for which they are=20
>authoritative.  Senders wishing to issue a query for a given=20
>record would first generate the solicited name multicast=20
>address corresponding to the record they wish to lookup.  Then=20
>they would send the query to that address.  Only those nodes=20
>listening to that particular multicast address would receive=20
>the packet, thus reducing significantly the amount of packet=20
>processing required by nodes participating in multicast DNS.
>
>Open issues:
>
>Size of multicast prefix and hash result.  I chose 104 and 24,=20
>respectively, simply because those are the lengths used for=20
>solicited node multicast addresses.  A smaller hash result=20
>would increase the likelihood of collisions, but the smaller=20
>address range might be more palatable to IANA.  The choice of=20
>hash function might also figure in here.
>
>What hash function to use?  Any half-way reasonable hash=20
>function would do, so it might be wise to use a hash function=20
>that all IPv6 implementations are required to have anyway. =20
>But MD5 and SHA-1 both seem a little overkill for this=20
>purpose.  The internet checksum isn't great, and only yields=20
>16 bits, but the code is present everywhere.  There are plenty=20
>of other possibilities.
>
>Comments?
>--Brian
>

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

---

From: Matt Crawford <[email-masked]>
Date: Tue, 17 Jul 2001 07:49:06 -0700

More precisely, convert to canonical form as defined by DNSSEC ...

    When the Subject is a domain name, either fully-qualified or
    single-component, and the Querier does not have a unicast address
    for the target node, the query MUST be sent to a link-scope
    multicast address formed in the following way.  The Subject Name is
    converted to canonical form, as defined by DNS Security [2535],
    which is uncompressed with all alphabetic characters in lower case.
    (If additional DNS label types for host names are defined, the rules
    for canonicalizing those labels will be found in the defining
    specification.)  Compute the MD5 hash [1321] of the first label of
    the Subject Name -- the portion beginning with the first one-octet
    length field and up to, but excluding, any subsequent length field.
    Append the first 32 bits of that 128-bit hash to the prefix
    FF02:0:0:0:0:2::/96.  The resulting multicast address will be termed
    the "NI Group Address" for the name.