Subject: Revision to resolution of Issue 28

From: Bernard Aboba <[email-masked]>
Date: Wed, 2 Apr 2003 23:38:13 -0800 (PST)

Based on Mika's comments, I'd like to propose a revision of the resolution
to Issue 28, as described below:

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 a link-local address or
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. A sender SHOULD prefer
RRs including reachable addresses where RRs involving
both reachable and unreachable addresses are returned in
response to a query."

--
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: Aidan Williams <[email-masked]>
Date: Wed, 16 Apr 2003 13:38:30 +1000

> Change:
...
> both reachable and unreachable addresses are returned in

Why does the proposed text start talking about "reachable"
and "unreachable" rather than "on link"?

Perhaps:
   A sender SHOULD prefer RRs including "on link" addresses where
   RRs involving both "on link" and "off link" addresses are
   returned in response to a query.

- aidan

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 15 Apr 2003 20:49:09 -0700 (PDT)

> and "unreachable" rather than "on link"?

See the discussion under Issue 28 on the LLMNR issues list:

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

The question is whether it is possible to know that a prefix is "on link".
With IPv6 this seems possible, but it is not clear for IPv4.

---

From: <[email-masked]>
Date: Wed, 16 Apr 2003 12:16:53 +0300

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Hi Aidan,

[Mailing from work now]

> Mika Liljeberg wrote:
> > The change was made because there is no easy way for an 
> application (=
> > LLMNR resolver) to check whether a particular address is 
> on-link. Not on
> > any operating system I know, anyway. There's no difference 
> between IPv4
> > and IPv6 in this respect.
> > 
> 
> Yes, I gathered that from reading the stuff on the issues web page
> and the mailing list.  I didn't really buy the check the routing
> table thing..

Why?

> The proposed solution seems like a bit of a fudge, (as in it doesn't
> address the fundamental issue of not being able to tell what is
> on-link) but because it is only a "preference" it probably won't
> hurt that much.

Yes, it could be clearer. But a clear requirement won't help if there is no clear way to implement it. It just means that different implementations will get it wrong in different ways.

It occurs to me that it would be a whole lot simpler to do the PTR queries using unicast. The LLMNR resolver could use a TTL=1 when sending the query. This way it would either get an immediate no-route response from the local TCPIP stack, a direct response from the holder of the address, or an ICMP time exceeded reply from the default router. Either way, the resolver wouldn't have to do any checking on the address. This approach has several benefits:

1) Immediate error response if there is no route for the address
2) Error response from default router if the address is off-link
3) LLMNR resolver does not need to do any checking on the address
4) Unicast is easier on the network

Note that conflict resolution for addresses is taken care by DAD, so using unicast for PTR shouldn't make any difference there. Another assumption is that the PTR query is already vulnerable to spoofing on the local link, so, as long as we use TTL=1 for the query there should be no perceivable additional risk.

> > [On-link determination would become trivial, by the way, if we only
> > allowed LLMNR to only advertise link-local addresses].
> 
> True..  but it appears people want to use it for more than that,
> at least in the IPv6 case.

Yes, IPv4 keeps muddying the water. LL's are always available with IPv6, so there should be no reason to advertise anything else.

	MikaL