LLMNR issue summary

[Bernard Aboba <aboba@internaut.com>]

There are currently 7 open LLMNR Issues:

Issue 2: TTL=255 on Send, Check on Receive?
Issue 3: Unsafe queries
Issue 6: IPv6 Multicast Groups
Issue 21: PTR queries
Issue 28: Addressing
Issue 29: Valid Responses
Issue 30: Why is Dynamic Updated Needed?

Issue 2

At IETF 56, the discussion seemed to indicate that sending with TTL=255
and checking on receipt would "do no harm" so that it was ok. The major
issues encountered in Zeroconf WG with IPv4LL don't seem to apply here,
since there are no legacy LLMNR implementations out there that set TTL to
something other than 255, so we have a clean slate. Also, even if the
IPv4LL draft doesn't specify setting or checking of TTL, an application
can still do so. So I'd like to recommend that we keep the existing -14
text that mandates setting TTL=255 and checking it.

Issue 3

The discussion at IETF 56 centered on how this would impact a typical use
case: two users, one with machine bernarda.microsoft.com and another with
randy.psg.com attempting to communicate over an adhoc network. The
proposed change would not allow these two machines to resolve each other's
name, since neither host exists within the other's "default domain".

One possible solution to this would be for the two machines to answer
queries for "bernarda" and "randy", rather than only answering queries for
the FQDN. If this would work, then the proposed rule is ok as is. What do
people think?

Issue 21

Back of the envelope calculations seem to indicate to me that
bogus PTR queries can be a significant problem in some cases. Measurements
show that a significant fraction of DNS queries are not answered, and this is
particularly true with PTR queries. So we can have a substantial amount of
bogus LLMNR PTR query traffic. I am particularly worried about wireless
networks with lots of people like at IETF 56. 5 queries a second from
3000 people would end up eating up a significant fraction of the total
bandwidth of an 802.11 network, particularly if there are lots of folks
who have to step down to lower rates (1,2,5 Mbps). So there is some reason
for concern.

In the discussion at IETF 56, there was concern that it might not be
possible for a host to know all the networks it was connected to. The
question then arises as to whether it is ok not to send a PTR query for
addresses on networks the host doesn't know about. It was pointed out that
if the host doesn't have a route for that address, then it will route the
packet to the gateway, which might not have a route for it either. The
question also arose as to why we *ever* want to send IPv6 PTR queries via
LLMNR. After all, the ICMP node information query accomplishes the same
thing and its use isn't restricted to linklocal. Why not use that instead?

So I would like to request feedback from DNSEXT WG on whether:

a. We need to send PTR queries at all via LLMNR. If we do, is this just
for IPv4? Both IPv4 and IPv6?

b. If we need to send them, does it make sense to restrict them to
networks on-link?

c. If we do send them even for networks off-link, how do you propose to
deal with the ensuing bogus traffic?

Issue 6

At IETF 56, the sentiment seemed to be for reducing the number of
multicast groups used for IPv6. The proposed text uses multiple groups for
A/AAAA queries, but a single group for all other queries. This would
result in a host with a single name, but multiple addresses listening on
only one multicast group for all the PTR RRs it has.

One question is whether the scalability benefits of multiple groups is
worth the complexity. In my mind, multiple groups do provide some scaling
benefits, but only if the overall traffic load is low. If the problem
outlined in Issue 21 isn't addressed, I think we will have a scaling
problem for multiple groups or a single group.

Opinions solicited.

Issues 28 and 29

This is similar to Issue 21, in that it is proposed that the receiver
check for an "on-link" address in the source address field of LLMNR
queries and responses. As with Issue 21, this causes queries or responses
sent from networks the host doesn't know about to be dropped. Is this
corner case something we need to worry about?

Issue 30

This issue claims that there is no benefit to doing a dynamic update with
pre-requisite NXRRSET in order to detect duplicate UNIQUE RRs. Instead,
why not just send an RR query? Perhaps someone can explain what the
benefit is -- and why it outweighs the additional complexity. Personally,
I do not see the benefit of dynamic update, but am willing to be convinced
otherwise.


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