Subject: Proposed Resolution to LLMNR Issue 48: Reachability of routable addresses

From: Bernard Aboba <[email-masked]>
Date: Sat, 27 Sep 2003 09:29:41 -0700 (PDT)

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

Change Section 3 to the following:

"LLMNR is a peer-to-peer name resolution protocol that is not intended as
a replacement for DNS. By default, LLMNR requests SHOULD be sent only
when no manual or automatic DNS configuration has been performed, when
DNS servers do not respond, or when they respond to a query with RCODE=3
(Authoritative Name Error) or RCODE=0, and an empty answer section.
An LLMNR sender may send a request for any name.

As noted in [DNSPerf], even when DNS servers are configured, a
significant fraction of DNS queries do not receive a response, or result
in negative responses due to missing inverse mappings or NS records that
point to nonexistent or inappropriate hosts. Given this, support for
LLMNR as a secondary name resolution mechanism has the potential to
result in a large number of inappropriate queries without the following
additional restrictions:

[1] If a DNS query does not receive a response, prior to falling
back to LLMNR, the query SHOULD be retransmitted at least
once.

[2] A sender SHOULD send LLMNR queries for PTR RRs
via unicast, as specified in Section 2.3.

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:

[1] If a link-scope IPv6 address is returned in a AAAA RR, that
address MUST be valid on the local link over which LLMNR is
used.

[2] If an IPv4 address is returned, it MUST be reachable through
the link over which LLMNR is used.

[3] If a name is returned (for example in a CNAME, MX
or SRV RR), the name MUST be valid on the local interface.

Routable addresses MUST be included first in the response, if available.
This encourages use of routable address(es) for establishment of
new connections."

--------------------------------------------------------------
Issue 48: Reachability of routable addresses
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: September  13, 2003
Reference:
Document: LLMNR-23
Comment type: T
Priority: S
Section: 3
Rationale/Explanation of issue:

If a host has both link-scope and routable addresses, it should only
prefer the routable address in
responses if that routable address is reachable on the interface on which
the query was received.  Otherwise the query sender could end up resolving
a name to an address that would not respond to ARP or ND/NS.

In Section 3 change:

"[2] 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."

To:

"[2] A responder with both link-local and routable addresses
on an interface MUST respond to LLMNR queries for
A/AAAA RRs only with routable address(es) reachable
on the interface receiving the query. This encourages
use of routable address(es) for establishment of new
connections."

[Markku Savela]
Object to must "MUST". I want to be able to reply with link-local
address, if the query src is using link-local address. And, I reply
with global addresses, if query source address is global.

[Bernard Aboba]
Section 1.4 of draft-ietf-zeroconf-ipv4-linklocal-09 states:

" In order to prevent use of Link-Local IPv4 addresses in off-link
communication, the following cautionary measures are advised:

a. Routable addresses should be used within applications whenever
they are available.

b. Names that are globally resolvable to routable addresses should be
used within applications whenever they are available. Names that are
resolvable only on the local link (such as through use of protocols
such as Link Local Multicast Name Resolution [LLMNR]) MUST NOT be
used in off-link communication. IPV4 addresses and names which can
only be resolved on the local link SHOULD NOT be forwarded, they
SHOULD only be sent when a Link-Local address is used as the source
address. This strong advice should hinder limited scope addresses
and names from leaving the context in which they apply.

c. Link-Local IPv4 addresses MUST NOT be configured in the DNS."

Since a routable address is used within applications whenever it is
available, a responder with a routable address receiving an LLMNR query
will respond to the LLMNR query using a routable source address. Since
the host does not use the Link-Local IPv4 address as the source,
it also does not respond with RRs containing the IPv4 Link-Local
address.

This also has the effect of ensuring that a sender querying via DNS
or LLMNR cannot receive conflicting answers. Since Link-Local
IPv4 addresses are not registered in DNS, a sender cannot receive
an RR containing a Link-Local IPV4 address as a response to a DNS
query. If the responder has no routable address to register in DNS,
then it cannot register any address, and so the sender will query
via LLMNR and can receive an RR in the response containing a
Link-Local IPv4 address. If the responder is multi-homed, then
it can register a routable address in DNS. If an LLMNR
query arrives on the interface using the routable address, then
the sender will reply using the routable address. If an LLMNR
query arrives on an interface using a Link-Local IPv4 address,
then the sender will reply using a Link-Local IPv4 address,
since the routable address is not reachable on that interface.

Replying with a routable address does no harm regardless of the
sender's source address, since a sender with only an IPv4
Link-Local address will "ARP for everything" and will be able
to contact the responder on a routable address.

[Mika Liljeberg]
I also object to the proposed wording.

On Sat, 2003-09-27 at 14:48, Bernard Aboba wrote:
> Replying with a routable address does no harm regardless of the
> sender's source address, since a sender with only an IPv4
> Link-Local address will "ARP for everything" and will be able
> to contact the responder on a routable address.

The zeroconf specification also recognizes that the "ARP for everything"
approach does not work for multihomed hosts. In addition, nodes that
rendezvous in an ad-hoc situation may have mismatching netmasks, which
will prevent them from communicating using the associated routable
addresses. In fact, a LLMNR responder has no reliable way of judging
which address may be usable for the sender and which might not.

Hence, the responder should just send all addresses it has and let the
client decide. Note that the client side stub resolver can be
implemented in such a way that it only returns usable addresses (or only
the "best" address) to the application.

A node only needs to configure a link-local address if a) it has no
routable address, or b) its routable address is not working. In other
words, a node that is compliant with zeroconf will only configure a
link-local address in addition to a routable one if it really needs one.
This being the case it is not appropriate for LLMNR to decide not to
advertise the address.

[Bernard Aboba]
One problematic scenario occurs where the sender has a routable address on
one interface and a link-local address on another interface. It sends an
LLMNR query on the interface with a link-local address and gets back a
response with a routable address. It might then attempt to contact the
responder via the interface with the routable address (since presumably
this interface also has the default route). If the address is not
reachable over that interface, then if the sender does not ARP for the
routable address on the link-local interface, then communication will
fail.

If the responder only has a routable address there is no alternative. If
it has both a routable address and an IPv4 LL address, then it could
respond with the routable address first, and the IPv4 LL address 2nd.
On failing to reach the responder over the interface with the routable
address, the sender could try the link-local address over the interface
with a link-local address. That would work.

However, the IPv4LL draft does not recommend configuring a single
interface with both a routable and a link-local address. Perhaps we could
say that the responder can only respond with addresses that are valid on
the interface on which the query is received, and that routable addresses
should be listed first?

> In fact, a LLMNR responder has no reliable way of judging
> which address may be usable for the sender and which might not.

I think this is true. However, the LLMNR responder does have the ability
to decide which of its addresses are reachable over the interface on which
a query is received.

> Hence, the responder should just send all addresses it has and let the
> client decide.

Sending addresses not reachable over the interface on which the query is
received is not helpful.

> Note that the client side stub resolver can be
> implemented in such a way that it only returns usable addresses (or only
> the "best" address) to the application.

In practice, I don't think that implementations are that likely to do
this.

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