Subject: Proposed resolution to LLMNR Issue 44

From: Bernard Aboba <[email-masked]>
Date: Sat, 30 Aug 2003 07:55:34 -0700 (PDT)

The text of Issue 44 is included below.  The proposed
fixes are as follows:

Change "224.0.0.251" throughout the document to TBD.

In Section 3, change:

"[2] Where a DNS server is configured, by default a sender
    SHOULD send LLMNR queries only for names that are either
    unqualified or exist within the default domain. Where no
    DNS server is configured, an LLMNR query MAY be sent for
    any name."

To:

"[2] Where a DNS server is configured, by default a sender
    SHOULD send LLMNR A or AAAA queries only for names
    that are either unqualified or exist within the default
    domain. Where no DNS server is configured, an
    LLMNR query MAY be sent for any name.  It is consistent
    with this recommendation for a sender to use LLMNR queries
    for the resolution of unqualified host names, and
    conventional DNS queries for resolution of other DNS
    names."

In Section 2.5, change:

"The source address of LLMNR queries and responses MUST be "on link"."

To:

"A transmitting host MUST select a source address for LLMNR queries
and responses that is "on link"."

Change Section 2.6 from:

"2.6.  Retransmissions

In order to avoid synchronization, LLMNR queries and responses are
delayed by a time uniformly distributed between 0 and 200 ms.

If an LLMNR query sent over UDP is not resolved within the timeout
interval (LLMNR_TIMEOUT), then a sender MAY repeat the transmission of
the query in order to assure that it was received by a host capable of
responding to it.  Since a multicast query sender cannot know beforehand
whether it will receive no response, one response, or more than one
response, it SHOULD wait for LLMNR_TIMEOUT in order to collect all
possible responses, rather than considering the multicast query answered
after the first response is received. A unicast query sender considers
the query answered after the first response is received, so that it only
waits for LLMNR_TIMEOUT if no response has been received.

LLMNR implementations SHOULD dynamically estimate the timeout value
(LLMNR_TIMEOUT) based on the last response received, on a per-interface
basis. The algorithms described in [RFC2988] are suggested, with a
minimum timeout value of 300 ms.  Retransmission of UDP queries SHOULD
NOT be attempted more than 3 times.  Where LLMNR queries are sent using
TCP, retransmission is handled by the transport layer."

To:

"2.6.  Retransmissions

In order to avoid synchronization, LLMNR queries and responses are
delayed by a time uniformly distributed between 0 and 200 ms.

If an LLMNR query sent over UDP is not resolved within the timeout
interval (LLMNR_TIMEOUT), then a sender MAY repeat the transmission of
the query in order to assure that it was received by a host capable of
responding to it.

Since a multicast query sender cannot know beforehand
whether it will receive no response, one response, or more than one
response, it SHOULD wait for LLMNR_TIMEOUT in order to collect all
possible responses, rather than considering the multicast query answered
after the first response is received. A unicast query sender considers
the query answered after the first response is received, so that it only
waits for LLMNR_TIMEOUT if no response has been received.

LLMNR implementations SHOULD dynamically estimate the timeout value
(LLMNR_TIMEOUT) based on the last response received for a query,
on a per-interface basis.

The algorithms described in [RFC2988] are suggested, with a
minimum timeout value of 300 ms.  Retransmission of UDP queries SHOULD
NOT be attempted more than 3 times.  Where LLMNR queries are sent using
TCP, retransmission is handled by the transport layer."

In Section 2.7 change:

"The responder should use a pre-configured TTL value in the records
returned in the LLMNR query response."

To:

"The responder should use a pre-configured TTL value in the records
returned in the LLMNR query response.  A default value of 30
seconds is recommended.  In highly dynamic environments
(such as adhoc networks) it may be necessary to set the TTL to a
lower value."

In Section 3, change:

"RRs returned in LLMNR responses MUST only include values that are valid
on the local interface, such as IPv4 or IPv6 addresses valid on the
local link or names defended using the mechanism described in Section 4.
In particular:"

To:

"It is the responsibility of the sender to ensure that
RRs returned in LLMNR responses MUST only include values that are valid
on the local interface, such as IPv4 or IPv6 addresses valid on the
local link or names defended using the mechanism described in Section 4.
In particular:"

Change section 3.1, from:

"The same host MAY use LLMNR queries for the resolution of unqualified
host names, and conventional DNS queries for resolution of other DNS
names.

If a name is not qualified and does not end in a trailing dot, for the
purposes of LLMNR, the implicit search order is as follows:

[1]  Request the name with the current domain appended.
[2]  Request just the name.

This is the behavior suggested by [RFC1536].  LLMNR uses this technique
to resolve unqualified host names."

To:

"If a name is not qualified, for the
purposes of LLMNR, the implicit search order is as follows:

[1] Request the name with the current domain appended.
[2] Request the name with the root domain (".") appended.

This is the behavior suggested by [RFC1536].  LLMNR uses this technique
to resolve unqualified host names."

In Section 3.2, change:

"Where there is no DNS server authoritative for the names of hosts on the
local network"

To:

"Where there is no DNS server authoritative for the name of at least one
of the hosts
currently on the local network"

Change:

"linklocal name resoltion over IPv4."

To:

"linklocal name resolution over IPv4."

In Section 4, change:

"Where a host is configured to respond to LLMNR queries on more than one
interface, each interface should have its own independent LLMNR cache."

To:

"Where a host is configured to issue LLMNR queries on more than one
interface, each interface should have its own independent LLMNR cache."

In Section 4, change:

"For each UNIQUE resource record in a given interface's configuration,
the host MUST verify resource record uniqueness on that interface. To
accomplish this, the host MUST send an LLMNR query for each UNIQUE
resource record.

By default, a host SHOULD be configured to behave as though all RRs are
UNIQUE.  Uniqueness verification is carried out when the host:

  - starts up or is rebooted
  - wakes from sleep (if the network interface was inactive during sleep)
  - is configured to respond to the LLMNR queries on an interface
  - is configured to respond to the LLMNR queries using additional
    UNIQUE resource records
  - detects that an interface is connected and is usable
    (e.g. an IEEE 802 hardware link-state change indicating that a
    cable was attached or that an association has occurred with a
    wireless base station and that any required authentication has
    completed)"

To:

"For each UNIQUE resource record in a given interface's configuration,
the host MUST verify resource record uniqueness on that interface. To
accomplish this, the host MUST send an LLMNR query for each UNIQUE
resource record, as described in Section 2.6.

By default, a host SHOULD be configured to behave as though all RRs are
UNIQUE.  Uniqueness verification is carried out when the host:

  - starts up or is rebooted
  - is configured to respond to the LLMNR queries on an interface
  - is configured to respond to the LLMNR queries using additional
    UNIQUE resource records"

Proposed Resolution: Accept

------------------------------------------------------
Issue 44: Miscellaneous Comments
Submitter name: Stuart Cheshire
Submitter email address: [email-masked]
Date first submitted: August 24, 2003
Reference:
Document: LLMNR-22
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

This is a busy time at Apple, working towards our next OS release,
but I managed to make time to read draft-ietf-dnsext-mdns-22.txt.

>The IPv4 link-scope multicast address a given responder listens
>to, and to which a sender sends queries, is 224.0.0.251.

If your intention is to make LLMNR interoperable with Rendezvous, I fully
support that, and would be willing to do the necessary work. For example,
Rendezvous does not currently support TCP queries, but we would be
willing to add that support, and things like it, if the WG wanted to
pursue that direction.

Otherwise, if the intention is not to make LLMNR interoperable with
Rendezvous, then it should not use the same multicast address. Using the
same multicast address, and then using a different UDP port number so as
to demultiplex the traffic in the kernel, would be the height of folly.
The whole point of multicast (as opposed to good old-fashioned broadcast)
is that it lets the Ethernet hardware (and/or the Ethernet switch) reduce
the interrupt burden on the host CPU (and/or reduce the traffic on that
link). Using the UDP port number as the filtering mechanism means that
you pay all the cost of delivering a packet to a host that doesn't want
it, only to have the packet discarded in the kernel because no one is
listening on that port. The whole point of multicast is to prevent that
waste.

>Today, with the rise of home networking, there are an increasing number
>of ad-hoc networks operating without a Domain Name System (DNS) server.

I think this is side-stepping the real issue. The real issue is:

>Today, with the rise of home networking, there are an increasing number
>of home users who do not have ownership of any part of the name space
>in which they can assign names.

The whole section talking about "unqualified names" seems to be skirting
around this issue without being willing to face it head-on and tackle it.
Section 3.1 says:

>3.1. Unqualified names
>
>The same host MAY use LLMNR queries for the resolution of unqualified
>host names, and conventional DNS queries for resolution of other DNS
>names.
>
>If a name is not qualified and does not end in a trailing dot, for the
>purposes of LLMNR, the implicit search order is as follows:
>
>[1] Request the name with the current domain appended.
>[2] Request just the name.

You can't "request just the name". There is no way to represent an
unqualified name ("no trailing dot") in the DNS packet format. What you
mean is:

>[1] Request the name with the current domain appended.
>[2] Request the name with the root domain (".") appended.

What this means is that if a home user calls their TV "tv", and their FM
radio receiver "fm", and their CD player "cd", their computer is going to
be sending queries for the TLDs "tv.", "fm." and "cd." (Tuvalu, Federal
State of Micronesia, and Democratic Republic of the Congo, respectively.)

This seems like it invites chaotic uncontrolled pollution of the
top-level name space.

[BA] I assume you are referring to DNS queries for "tv."  Presumably there
is no harm in allowing LLMNR queries for this.  The draft allows a host to
resolve queries for unqualified names only via LLMNR, so this can be
avoided. Are you suggesting that this behavior be recommended?

Furthermore, because there is no way to represent an unqualified name in
the DNS packet format, there is also no way to represent an unqualified
name on the right-hand-side of a PTR, CNAME or SRV record. This means
that if you do a LLMNR query for an SRV record with an "unqualified"
name, what you get back is an SRV record containing a target host name
that you can't use with LLMNR because it's not an "unqualified" name.

[BA] Agreed. This should be fixed. See resolution above.

>Unicast queries SHOULD be sent when:
>
> b. The sender queries for a [reverse mapping] PTR RR.

Rendezvous has something called sleep proxy service, where a device can
transfer its RRs to a sleep proxy server on the local LAN and then go
into low-power sleep mode. The sleep proxy server answers queries on the
device's behalf, and wakes the device with a magic packet when an A or
SRV query is detected that indicates the device needs to wake up to
provide some active service. Sending queries via unicast means the sleep
proxy server may not get to see them, and may be unable to answer and/or
wake the device.

[BA] It also means that other hosts won't see these queries.  On a high
populated network such as the IETF's, such queries could consume a
substantial percentage of all bandwidth, and so it is desirable to limit
them.

>The source address of LLMNR queries and responses MUST be "on link".

Is this "MUST" a requirement imposed on senders, or a checking
requirement imposed on receivers?

[BA] On senders. There is no checking requirement on receivers.

>it is possible that some routers may not properly implement
>link-scope multicast

This is far fetched. How many routers *DO* implement multicast
forwarding, but *DON'T* understand 224.0.0/8? It's not a plausible
scenario. Rendezvous has been sending to 224.0.0.251 with TTL 255 for
over a year (longer if you count OS 9) and there have been no problems
reported.

[BA] Just because there have been no "problems reported" does not mean
that there aren't offending home gateways. This might not be an issue
because the multicast packets are dropped deeper in the network.

>The responder should use a pre-configured TTL value

Pre-configured by whom?

[BA] By the implementation.

>[3] A responder with both link-local and routable addresses
> MUST respond to LLMNR queries for A/AAAA RRs only with
> routable address(es). This encourages use of routable
> address(es) for establishment of new connections.

This creates failures where failures were not necessary. Just put all
answers in the response, and let the client use them intelligently: If
the routable address works, great, otherwise, the client can try the LL
to see if that works. Omitting the LL from the response does not help the
client work better: it prevents the client from connecting in situations
where it should be able to. (In some cases of network problems, omitting
the LL addresses may prevent you from connecting to the some piece of
network infrastructure to correct the misconfiguration that led to the
problem in the first place.)

[BA] The ZEROCONF WG has recommended this behavior to encourage use of a
routable address when it is available.  The routable address is likely to
be more stable, and since the IPv4 LL draft will incorporate behavior to
allow hosts with routable and IPv4 LL addresses to communicate, I'm not
sure why this should be an issue. Since LLMNR is about linklocal name
resolution, a host configured to ARP for addresses on the local link
(whether they are routable or IPv4 LL) should be able to reach both types
of addresses.

>3.1. Unqualified names
>
>The same host MAY use LLMNR queries for the resolution of unqualified
>host names

Who makes the choice offered by that "MAY"? User? OS vendor? Application
writer?

[BA] The LLMNR implementation.

>If a name is not qualified and does not end in a trailing dot,

What does that mean? Do "fully qualified" and "ends in a trailing dot"
mean the same thing, or is there a difference?

[BA] They means the same thing.  See proposed resolution above.

>Where there is
>no DNS server authoritative for the names of hosts on the local network

What does that mean?

What is the area code for mobile phones at an IETF meeting?

The statement doesn't have well-defined meaning.

My laptop computer has a name, and its name is not determined by its
geographic location at any given time.

DNS servers are authoritative for pieces of the name space, not for
physical networks.

Perhaps the text should say, "Where there is no DNS server authoritative
for the name of at least *one* of the hosts *currently* on the local
network..."

[BA] Agreed.

>Where a host is configured to respond to LLMNR queries on more than one
>interface, each interface should have its own independent LLMNR cache.

Perhaps you mean "configured to *issue* LLMNR queries on more than one
interface"

[BA] Yes.

>For each UNIQUE resource record in a given interface's configuration,
>the host MUST verify resource record uniqueness on that interface. To
>accomplish this, the host MUST send an LLMNR query for each UNIQUE
>resource record.

How many LLMNR queries? What interval?

How long after the query (or queries) may it start issuing responses for
that name?

[BA] UNIQUEness verification is handled similarly to any other query, as
specified in Section 2.6.

What about tie-breaking in the event of simultaneous startup (e.g. when
power is restored after an outage)?

[BA]  The draft does not specify what is done in the event of a name
conflict.  In general, automatic name change may be neither possible nor
desirable.

>For example, the hostname could be chosen randomly from a large pool of
>potential names

Doesn't this miss the point of hostnames? The whole point of using names
instead of dotted-decimal IP addresses is that names are supposed to be
more memorable, and easier for humans to type. If we're going to use
randomly chosen names, then we already have a mechanism for randomly
choosing from a pool of potential identifiers: it's called a DHCP server.
Isn't the point of LLMNR to let people pick a name for their machine
that's a little more convenient and friendly than
"dhcp-dynamic-191-72-231-201.ietf-53.ietf.org."?

[BA] This is just cited as an example of how name conflict can be avoided.
It is not being recommended necessarily -- and could be usable in
situations where no human intervention is anticipated.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>