Subject: Re: Proposed resolution to LLMNR Issue 21 (and 7)

From: Markku Savela <[email-masked]>
Date: Mon, 17 Mar 2003 22:58:50 +0200

> Add the following text to Section 3:
> 
> "[3] A sender SHOULD NOT send LLMNR queries for PTR RRs that
> correspond to addresses known not to exist on the local link.
> Since legitimate responses to LLMNR queries can only come from
> hosts on the local link, an LLMNR query for an address not
> on the local link cannot elicit a legitimate response."

How is LLMNR supposed to find out whether an address is on link or
not?

I think this is getting really complex. I suggest that LLMNR only
deals with link local addresses. Which brings me to the Issue 7

> Add the following text to section 4:

> "[4] A responder with both linklocal and routable addresses
>    SHOULD respond only to LLMNR queries for A/AAAA RRs for
>    the routable address. This encourages use of the routable
>    address for establishment of new connections."

I would go the other way: LLMNR should only return link local
addresses, never routable address.

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

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 17 Mar 2003 17:54:35 -0800 (PST)

> How is LLMNR supposed to find out whether an address is on link or

Presumably it looks at the routing table.

> deals with link local addresses. Which brings me to the Issue 7

We don't have that option for IPv4. Zeroconf WG has decided that for IPv4,
a linklocal address isn't advertised if a routable address is available.

> addresses, never routable address.

Since for IPV4 we'll not be able to do that, the question is whether IPv6
should behave differently.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 18 Mar 2003 07:04:06 -0800 (PST)

> That decision has problems that zeroconf has not yet been able to solve.
> In a nutshell: two nodes with different configured netmasks are unable
> to communicate on the local link, unless they also have link-local
> addresses. [There are ad-hoc scenarios where this can easily happen.]

If you disagree with the resolution of LLv4 Issue #23, I'd suggest
that you bring that up on the Zeroconf WG mailing list. Here's the text as
adopted:

"Having addresses of multiple different scopes assigned to an interface
with no adequate way to determine in what circumstances each address
should be used leads to complexity for applications and confusion for
users. A node with any address assigned for a link can communicate with
all other devices on that link, whether those other devices use link-local
addresses, or routable addresses.

For this reason, a host that obtains, or is configured with, a routable
address on an interface, SHOULD NOT attempt to configure a
link-local address on the same interface.

Where a link-local address has been configured on an interface, and a
routable address is later configured on the same interface, the host
MUST always use the routable address when initiating new communications,
and MUST cease advertising the availability of the link-local address
through whatever mechanisms that address had been made known to others.

A host SHOULD continue to use the link-local address for communications
underway when the routable address was configured, and MAY continue to
accept new communications addressed to the link-local address."

> At this point, it would be prudent to advertise all IPv4 addresses a
> node has and leave it to the client node to choose an appropriate
> address.

Since the language says MUST cease, I don't believe that we have the
option of continuing to advertise LLv4 addresses via LLMNR if a routable
address is also available. Of course, there is no such mandate for IPv6,
so we could take a different course there (although justification is
required, for course).

---

From: Mika Liljeberg <[email-masked]>
Date: 18 Mar 2003 23:42:22 +0200

> so we could take a different course there (although justification is

Since LLMNR includes two parts: a responder and a resolver, I think we
can meet the requirements of zeroconf by doing the following: the
responder can advertise *all* addresses, however, the resolver must make
a route check for the candidate address list and *only* return the
highest scope reachable address(es) to the application. This, IMHO, is
compliant with the zeroconf requirement.

Incidentally, the above will also work correctly for IPv6. The route
check in the resolver is also required by the rules laid out by IPv6
default address selection (RFC3484).

	MikaL