Subject: RFC 4795 (LLMNR) issues and errata

From: Alfred Hönes <[email-masked]>
Date: Tue, 13 Feb 2007 21:39:17 +0100 (MEZ)

Hello,
last weekend, I studied the recently published RFC 4795 (LLMNR)
authored by you.  Since I for last time had looked at a draft
version of that memo, roughly 20 months ago, some significant
changes have been introduced, and, unfortunately, I also find
some issues left in the published RFC.

As usual, the items below are presented in RFC textual order.
I use change bars ('|' in column 1) and occasionally
up/down pointing marker lines ('^^^'/'vvv') to emphasize
the location of textual issues and/or proposed corrections.
Modified text has been re-adjusted to match RFC formatting
rules, where appropriate.

(1)  Section 2.1.1 -- internal mis-ref. ?

On page 6, the explanation of the 'C' bit says:

             [...].  Responders MUST NOT respond to LLMNR queries with
|          the 'C' bit set, but may start the uniqueness verification
|          process, as described in Section 4.2.

This is a mix-up of the title of Section 4.1 and the section
number 4.2.
I strongly suspect that it was intended to refer to the procedures
outlined in the second half of Section 4.2 (paragraph 4 ff.).

If that's true, to avoid confusion, the RFC should better say,
rephrasing the title of Section 4.2 :

             [...].  Responders MUST NOT respond to LLMNR queries with
|          the 'C' bit set, but may start the conflict detection and
|          defense process, as described in Section 4.2.

Otherwise, the trailing "4.2." should be corrected to say "4.1."

(2)  under-specification for the non-UNIQUE case, clarification

Most parts of the RFC deal with the critical scenario of UNIQUE
names.  Nevertheless, the text in Section 4, at the bottom of
page 18, points out another important case, where LLMNR can
achieve much better service than DNS:

   By default, a responder SHOULD be configured to behave as though its
   name is UNIQUE on each interface on which LLMNR is enabled.  However,
|  it is also possible to configure multiple responders to be
|  authoritative for the same name.  For example, multiple responders
|  MAY respond to a query for an A or AAAA type record for a cluster
|  name (assigned to multiple hosts in the cluster).

When reading other parts of the RFC, I miss clear specifications
to handle this case.  (Please correct me if I have overlooked
something important.)

The issue is entangled with the question whether such cluster
member should be called "authoritative" for the non-UNIQUE name.
The definition of "Responder" in Section 1.2 clearly says 'yes',
but other places in the text apparently do not follow this
terminology.

In Section 2.1.1, the explanation of the 'T' bit (spanning from
the bottom of page 6 to the top of page 7) says:

|  T       Tentative.  The 'T'entative bit is set in a response if the
|          responder is authoritative for the name, but has not yet
|          verified the uniqueness of the name.  A responder MUST ignore
           the 'T' bit in a query, if set.  A response with the 'T' bit
<< page break >>
           set is silently discarded by the sender, except if it is a
|          uniqueness query, in which case, a conflict has been detected
|          and a responder MUST resolve the conflict as described in
           Section 4.1.

The major problem is in the first sentence:
According to 1.2, the responder is authoritative for the non-UNIQUE
name -- otherwise it would not be a responder for that name, making
the useful scenario with non-UNIQUE names impossible.
But because the name is non-UNIQUE, it will never be able to verify
the uniqueness of the name -- and in fact it should never try to do
so for names configured as non-UNIQUE (last bullet of 1.2).
Following this first sentence verbatim, any (authoritative) responder
for a non-UNIQUE name ought to set 'T' bit in the response, which,
in turn -- according to the third sentence quoted -- would cause the
sender to silently discard the response, again turning the scenario
un-usable.

This can not have been the intension of the specification.

I have tried to thoroughly cross-check other parts of the document,
and apparently, the proper solution (not causing harm otherwise)
would be to have the 'T' bit being cleared in responses for non-
UNIQUE names.  If that is correct, the above explanation should
be clarified by the addition of a statement to this end.

Yet, there's another issue with that snippit:  The last sentence
uses the term, "uniqueness query", which is not defined precisely
anywhere in the memo; the 4th paragraph of Section 2.7 uses the
similar term, "uniqueness verification query", which perhaps
should designate the same thing.
AFAICS, such a "uniqueness query" cannot be distinguished by a
responder from any other query, at the bits-on-the-wire level.
But that doesn't matter here, because the abuse of language,
"A response ... is ... discarded, except if it is a uniqueness query."
should be corrected anyway.  The text should perhaps better say:
"..., except if it is received in reply to a uniqueness query."
(The sender of that query indeed knows why it has been sent!)

Finally, when more than one query and response are being dealt
with, the term "responder" becomes ambiguous.  In Section 4.1
this might be acceptable (see below) because of the full context,
but here, the final "responder" might be very misleading
(apparently, that's the *sender* of the "uniqueness query").
I propose to rephrase the last half-sentence omitting the actor(s)
and let Section 4.1 give the details.

Taking altogether, the explanation of the 'T' bit should perhaps
be clarified to say:

   T       Tentative.  The 'T'entative bit is set in a response if the
|          responder is authoritative for a UNIQUE name, but has not yet
|          verified the uniqueness of the name, and it is cleared in all
|          other cases.  A responder MUST ignore the 'T' bit in a query,
           if set.  A response with the 'T' bit set is silently
|          discarded by the sender, except if it is received in reply to
|          a uniqueness query issued according to the rules in Section
|          4.1, in which case, a conflict has been detected and that
|          conflict MUST be resolved as described in Section 4.1.

I hope this modified version indeed says what was intended to say,
and that it clarifies all the points raised above.

(3)  Section 2.3 -- typo

For relaxation, that's an easy stuff:

In the second-to-last paragraph on page 10, Section 2.3 of RFC 4795
says:

                        [...].  The purpose of limiting the name
   authority scope of a responder is to prevent complications that could
|  be caused by coexistence of two or more hosts with the names
   representing child and parent (or grandparent) nodes in the DNS tree,
   for example, "foo.example.com." and "child.foo.example.com.".

It should say:

                        [...].  The purpose of limiting the name
   authority scope of a responder is to prevent complications that could
|  be caused by the coexistence of two or more hosts with the names
   representing child and parent (or grandparent) nodes in the DNS tree,
   for example, "foo.example.com." and "child.foo.example.com.".

(4)  Section 2.5 -- typos and mis-specification

(4a)
Within Section 2.5, the first paragraph on page 12 says:

   On receiving an LLMNR query, the responder MUST check whether it was
|  sent to an LLMNR multicast addresses defined in Section 2.  If it was
|  sent to another multicast address, then the query MUST be silently
|  discarded.

First of all, the first sentence should use "address" in place of
"addresses", or say "... to one of the LLMNR multicast addresses ...".

The much more serious issue is with the second sentence.
Following this sentence literally would prematurely disallow the
use of port 5355 as an ephemeral port for any other UDP unicast or
multicast application(s), which does not make sense, and which
IMHO is not necessary for proper operation of LLMNR.  (And systems
not implementing LLMNR would not follow this rule, anyway!)

To quote preceding text of the RFC:

- Section 2 says:

   LLMNR queries are sent to and received on port 5355.  The IPv4 link-
   scope multicast address a given responder listens to, and to which a
   sender sends queries, is 224.0.0.252.  The IPv6 link-scope multicast
   address a given responder listens to, and to which a sender sends all
   queries, is FF02:0:0:0:0:0:1:3.

- and Section 2.3, near the bottom of page 9, says:

   (a)  Responders MUST listen on UDP port 5355 on the link-scope
        multicast address(es) defined in Section 2, and on TCP port 5355
        on the unicast address(es) that could be set as the source
        address(es) when the responder responds to the LLMNR query.

An LLMNR Responder following this specifications, i.e. binding an
IPv4 datagram socket to {224.0.0.252,5355} and/or an IPv6 datagram
socket to {FF02::1:3,5355}, according to its IPv4/IPv6 support
(and interface-specific configuration), will never receive UPD
packets addressed to any other multicast addresses (or to any
other destination port), will never know if such a packet looks
like an LLMNR query, and does not need to discard such packets.

I propose to correct the first paragraph on page 12 (as quoted above)
to say:

   On receiving an LLMNR query, the responder MUST check whether it was
|  sent to one of the LLMNR multicast addresses defined in Section 2,
|  or via TCP.

(BTW, that's quite trivial, and perhaps does not even require
 RFC 2219 specification language.)

But if you prefer, an errata note could also ask for deletion of
the whole paragraph.

(4b)
In the third paragraph on page 12, for uniformity, the first sentence,

   For UDP queries and responses, the Hop Limit field in the IPv6 header
|  and the TTL field in the IPV4 header MAY be set to any value.
                              ^
should say:

   For UDP queries and responses, the Hop Limit field in the IPv6 header
|  and the TTL field in the IPv4 header MAY be set to any value.
                              ^

(5)  Section 3.1

This section contains probably much too 'optimistic' statements
on related work.

(5a)
The second paragraph says:

   Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to
   configure LLMNR on an interface.  The LLMNR Enable Option, described
   in [LLMNREnable], can be used to explicitly enable or disable use of
   LLMNR on an interface.  The LLMNR Enable Option does not determine
   whether, or in which order, DNS itself is used for name resolution.
   The order in which various name resolution mechanisms should be used
   can be specified using the Name Service Search Option (NSSO) for DHCP
   [RFC2937], using the LLMNR Enable Option code carried in the NSSO
   data.

AFAICS, [LLMNREnable] has never been finalized.
Section 8.2 apparently refers to <draft-guttman-dhc-mdns-enable-02>
-- which seems to have been a very popular reference.
Nevertheless, using common web search engines, I was not even able
to locate any online copy of the -02 version, only myriads of
references to it.
So perhaps this was just the 'tombstone' file for the expired -01
version (dated July 20, 2001), also available as the single matching
result from <http://tools.ietf.org/id/draft-guttman-dhc-.*> !

Also, apparently a DHCP option number has never been assigned to
this draft by the IANA (IESG approval would have been required!).

Therefore, this option 'can' *not* be used, and an option number
for it cannot be plugged into the NSSO (DHCP Opt.#117) data.

Thus, the 'Science Fiction' (or better: 'Engineering Fiction' ?)
in the above quoted paragraph should perhaps better be aligned
with reality by changing all occurrences of "can" into "could".

(5b)
The fourth paragraph of Section 3.1 says:

                               [...].  Automatic IPv6 DNS configuration
   mechanisms (such as [RFC3315] and [DNSDisc]) are not yet widely
   deployed, and not all DNS servers support IPv6.  [...]

Apparently, [DNSDisc] refers to the long expired I-D,
<draft-ietf-ipv6-dns-discovery-07> .
Admittedly, some of the ideas of that draft have survived in the
IANA IPv6 (anycast) address registry and in other recent work in
progress, but -- independent of the "success history" of IPv6
deployment at large -- talking about "not yet widely deployed"
in this context seems to be an euphemism !

(6)  Section 4.1

(6a)
In support of the enhancements discussed in item (2) above,
I propose to clarify the first paragraph of Section 4.1,

   Prior to sending an LLMNR response with the 'T' bit clear, a
   responder configured with a UNIQUE name MUST verify that there is no
   other host within the scope of LLMNR query propagation that is
   authoritative for the same name on that interface.

by adding another sentence, to say:

   Prior to sending an LLMNR response with the 'T' bit clear, a
   responder configured with a UNIQUE name MUST verify that there is no
   other host within the scope of LLMNR query propagation that is
|  authoritative for the same name on that interface.  Responses for
|  non-unique names are always sent with the 'T' bit clear.

[ Again, I hope that's what is intended. ]

(6b)
The use of the term, "responder", reaches its limitations in
this section; in particular, the first paragraph on page 20
is very hard to understand: there, the responder *reveives*
the response (sic!).  I had to read the whole Section again
until it became clear that that was not in error!

Section 1.2 already makes the roles of "responder" and
"authoritative [server]" synonymous.

Future derived work should perhaps reconsider the use of terms.
The conventional terms 'client' and 'server' for the roles of
the LLMNR entities would have avoided these terminological
idiosyncrasies.  (It is not unusual for other protocols
as well to have the same entity performing both roles --
for instance, a DNS recursive resolver!)

(7)  Section 4.2

The second paragraph has interspersed an inadvertant blank line.

(8)  Section 6  -- incomplete

For the benefit of the reader, the IANA Considerations section,
in the RFC published version, usually contains a summary of the
assignments performed by the IANA on behalf of the document.

Therefore, the following note should be added to Section 6
of RFC 4795:

   IANA has allocated to LLMNR:
   - server port 5355 for both TCP and UDP;
   - the link-scope IPv4 multicast address 224.0.0.252 ;
   - the link-scope IPv6 multicast address FF02::1:3 .

[ or similar ]

This concludes my notes on RFC 4795.
Once again, I apologize for not having found the time to perform
a detailed review before publication.

Please comment (it doesn't hurry!).

Many of the items above seem to be appropriate for an RFC Errata
Note; but I leave it to your decision whether this should be done,
possibly to promote interoperable implementations of the proposal,
or if you prefer to just make notice of these comments, for
consideration in possible future derived work.

Preferrably, you should submit an Author's Errata Note to the
RFC Editor's RFC Errata web pages, making freely use of the
material supplied above.  But if you like, I can formally
submit an Errata Note on my own, with your consent.

Best regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+