Subject: Revised Proposed Resolution of Issue 47: Miscellaneous Issues

From: Bernard Aboba <[email-masked]>
Date: Thu, 11 Sep 2003 14:03:51 -0700 (PDT)

The text of Issue 47 is enclosed below.  The proposed fix is as follows:

In Section 2.5, change:

"The source address of LLMNR queries and responses MUST be "on link".
The destination address of an LLMNR query MUST be a link-scope multicast
address or an "on link" unicast address; the destination address of an
LLMNR response MUST be an "on link" unicast address.
On receiving an LLMNR query, the responder MUST check whether it was
sent to a LLMNR multicast addresses defined in Section 2.4.
If it was sent to another multicast
address, then the query MUST be silently discarded."

To:

"A sender MUST select a source address for LLMNR queries
that is "on link".  The destination address of an LLMNR query
MUST be a link-scope multicast address or an "on link" unicast address.

A responder MUST select a source address for responses that is
"on link". The destination address of an
LLMNR response MUST be an "on link" unicast address.
On receiving an LLMNR query, the responder MUST check whether it was
sent to a LLMNR multicast addresses defined in Section 2.4.
If it was sent to another multicast address, then the query MUST be
silently discarded."

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 0 is recommended
in highly dynamic environments (such as mobile ad-hoc networks).  In more
static environments, LLMNR traffic can be reduced by setting the TTL to a
higher value."

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 responder 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:"

In Section 3.2, change:

"Where there is no DNS
server authoritative for the names of hosts on the local network or
the authoritative DNS server does not support dynamic client update
over IPv6 or DHCPv6-based dynamic update, hosts on the home network
will not be able to dynamically register or resolve the names of
local IPv6 hosts."

To:

"Where there is no DNS server authoritative for the name
of a host or the authoritative DNS server does not support dynamic
client update over IPv6 or DHCPv6-based dynamic update, then an
IPv6-only host will not be able to do DNS dynamic update,
and other hosts will not be able to resolve its name."

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
- wakes from sleep (if the network interface was inactive during sleep)
- is configured to respond to the LLMNR queries on an interface enabled
for transmission and reception of IP traffic
- is configured to respond to the LLMNR queries using additional
UNIQUE resource records"

-----------------------------------------------------------------
Issue 47: Miscellaneous Issues
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:

>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.

>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,
because by setting TTL=1 the possibility of DoS amplification
is removed. If TTL=255 were set on unicast responses, then
it would be possible for LLMNR UDP responses to leak beyond
link-scope if unicast UDP queries were to be allowed. For
TCP this is not an issue since TTL=1 ensures that the 3-way
handshake cannot succeed if unless the endpoints are on-link.

>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] As recently as a year ago, we have seen routers that don't
properly implement link local multicast, so we disagree on this.

>The responder should use a pre-configured TTL value

Pre-configured by whom?

[BA] By the implementation. It probably makes sense to add
some text suggesting appropriate default values.

>[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.

>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/>