Subject: Proposed Resolution of LLMNR Issue 28

From: Bernard Aboba <[email-masked]>
Date: Mon, 31 Mar 2003 21:00:47 -0800 (PST)

I would propose to accept the change proposed in Issue 28. Any objections?

Issue 28: Addressing
Submitter: Christian Huitema
Submitter email address: [email-masked]
Date first submitted: January 17, 2003
Reference:
Document: LLMNR-13
Comment type: T
Priority: S
Section: 2.5
Rationale/Explanation of issue:

Change:

"For IPv4 link-scope addressing, section 2.4 of "Dynamic Configuration of
IPv4 Link-Local Addresses" [IPV4Link] lays out the rules with respect to
source address selection, TTL settings, and acceptable
source/destination address combinations. IPv6 is described in [RFC2460];
IPv6 link-scope addressing is described in [RFC2373]. LLMNR queries and
responses obey the rules laid out in these documents. "

To:

"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.
For IPv4, an "on link" address is defined as an address whose prefix
belongs to a subnet on the local link; for IPv6 [RFC2460]
an "on link" address is either a link-local address, defined in
[RFC2373], or an address whose prefix
belongs to a subnet on the local link. LLMNR senders or responders
receiving LLMNR packets from a source address that is not "on link"
SHOULD silently discard them. "

--
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: Erik Nordmark <[email-masked]>
Date: Tue, 1 Apr 2003 22:57:56 +0200 (CEST)

> SHOULD silently discard them. "

[With interested participant hat on]

The above is an improvement over the old text but doesn't cover the case when 
the responder can't tell whether an address is on link.
Is that a separate issues that is being resolved separately?

  Erik

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 1 Apr 2003 16:27:12 -0800 (PST)

> Is that a separate issues that is being resolved separately?

There are several related issues: 28, 29 and 21 that use the term
"on-link". See the LLMNR issues list for all the proposed text and
discussion:

http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html

As noted in one of the comments on Issue 21:

If you don't know about the other guy's prefix, he may not know
about yours either, in which case he'll get your multicast request but
try to send a unicast response via the router, which may decrement the TTL
when forwarding it back onto the same link. I'm not sure LLMNR will
work in this case (due to the TTL 255 check), but even if it works, I think
a configuration where hosts have to communicate (even only initially)
via a router is out-of-scope for LLMNR. Let traditional DNS handle that
case; we don't need LLMNR there.